ITSTEM JOURNAL 


ÖS 150, DM 19,80 sfr 19,80 





OS/2-Wissen verständlich: Gerätetreiber 


Die Grafikprogrammierschnittstelle des Presentation Managers unter MS-DOS 
Koordination von Threads mit Semaphoren 
Das Dateisystem von MS-OS/2 





Programmierbeispiele für Einsteiger: TIFF: Das neue Standard- 


Dynamische Speicherverwaltungstechniken in C format für Grafiken 
Terminalemulation mit QuickBASIC 












Kompaktes Wissen üher 


Betriehs- 


H.H.Gerhardt: DOS 33 für PCs und Personal System/2 
1988, 334 Seiten 

‚Eine leichtverständliche Einführung mit Beispielen, 
Übungen und alphabetischer Belehlsübersicht. Für 
‚Anfänger und Fortgeschrittene. Mit umfangreichem 
‚Anhang: Begrifiserklärung, Zeichencode Tabellen, Kurs 
darstellung zum Thema «Netzwerke, Fehlerübersicht, 
Übersicht zu den »DOS Function Calls« und »DOS Inter- 
upt Calls«, 

‚Bestell-Nr. 90547 ISBN 3-89090-.547-1 

DM69,SFr 6350605 538.20 


fü 
Personal System/2 





SSR PMonadiemi: PC-Programmierung in Maschinensprache 
1988, ca.300 Seiten, Inkl. Diskette 
Eine Einführung in die 8086/8088-Maschinensprachepro- 4 BE  H.H.Gerhard: PC-DOSMS-DOS 3.2 
‚grammierung mit vielen Beispielen. Zahlreiche Assembler- »‚. 1987, 299 Seiten, inkl. Diskette 
routinen und ein ASCII-Texteditor sind auf der beigefügten Eine Einführung in die wichtigsten Grundlagen zur 
Diskatte enthalten. Mit allen Belehlen und einem Assembier- Bedienung Ihres PCs mit DOS sowie ein hileic 
Glossar Im Anhang. Nachschlagewerk für jeden DOS-Anwender. Mit aus- 
BestelkN. 90503 ISBN 3-89090-503:X u ührlichen Belehlsbeschreibungen, alphabetischen 
DM 69,-/5Fr 6350605 538.20 Nachschlagetei und vielen Beispielen im PC-DOS- 
und MS-DOS-Format auf Diskette. 
Bestel-Nc 90519 ISBN 3-89090-519-6 
DMS9;/sFr 5430008 450.20 













H.Drees: Unix 
1988, ca.600 Seiten 

Ein umtassendes Kompendium für Anwender 
und Systemspezialisten. Es beschreibt kein 
spezielles Unix, sondern Unix schlechthin 
und stützt sich dabei auf den Leistungs- 
standard, der durch Unix V repräsentiert 
wird, Mit vielen Beispielen und Anregungen. 
Bestel-iNi: 90494 ISBN 3-89090-494-7 


DM 89,/5Fr 8190005 694,20 - 2 Kncrosoft 


U.Schmidt 
Daten retten mit Norton Utilities. 
2, überarb, Aufl, 1987, 301 Seiten 
‚Das Übungsbuch zum Programm- Dr. Norbert Meder: MS-OSI2 
paket mit ausführlichen Beispielen 1988 304 Seiten. 
zur Rettung gelöschter Daten, Einführung und Überblick 
Disketten/Festplatten-Organisation, über die neuen Program- 
U Schmidt: Das MS-Windows-Kompendium 2 universellen Textsuche und miermöglichkeiten von 
1988, ca.350 Seiten, inkl. zwei Disketten vielem meh. MS-OS/2. Den Schwerpunkt 
Tips, Thicks und Training, eine ausführliche Bestell-Nr 90505 bildet der neue Befehlsworrat 
Programmdokumentation und Hilfen bei der ISEN-3.89090-5056 von MS-OS/2. Die einzelnen 
‚Anpassung verschiedener Softwarepakete DM 49,-/SFr 45.1008 382,20 ‚Befehle werden anhand von 
inden Sie in diesem umfangreichen Kom- Beispielen leichtverständlich 
pendium. Für Windows 20 und 386. Auf erläutert. Auch die Baich- 
den zwei Disketten finden Sie ein ausführ- Programmierung wird 
liches Hilsprogramm mit Installations: behandelt. 
programm für die Festplatte, Unities und BestellNe. 90512 
‚zahlreiche Beispiele ISBN 39090512: 
Bestel.Nr. 90558 ISBN 389090-558-7 DM 79-/5Fr 72.2065 616.20 
DM 69,SFr 635005 538.20 


Do y— Zn Markt&Technik-Produkte erhalten Sie bei Ihrem 


Buchhändler, in Computer-Fachgeschäften oder in den 
Fachabteilungen der Warenhäuser. 
















Irrtümer und Änderungen vorbehalten. 


Markt&@echnik 


Zeitschriften - Bücher _ 
Software - Schulung 
z nn ‚Fragen Sie bei Ihrem 


Markt& Technik Verlag AG, Buchverlag, Ha: Straße 2, / 7 Buchhändler nach unserem 
8013 Haar bei München, Telefon (089) 4613-0. kostenlosen Gesamtverzeichnis 
SCHWEIZ: Markt& Technik Vertriebs AG, Kollerstrasse 3, CH-6300 Zug, Telefon (04. ä mit über 500 aktuellen 
ÖSTERREICH: Markt&Tachnik Verlag Gesellschaft m.b.H., Große Neugasse 28, A-1040 Wien, Telefon (022 Computerbüchern und Software. 
‚Rudolf Lechner& Sohn, Heizwerkstraße 10, A-1232 Wien, Telefon (0222) 6 / Oder fordern Sie es direkt 
Ueberreuter Media Verlagsges.mbH (Großhandel), Laudongasse 29, A-1082 W 0 / beim Verla 


Ausgabe Juli/August 1988 


SITE Journ 





Microsoft Windows 





Ein Interview mit den 
Excel-Entwicklern .. 





Anzeige des freien Speichers 
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TIFF: Der neue Grafikstandard 


Mitglieder des Excel-Programmierteams berichten in diesem 
Interview über die Vorteile der Windows-Umgebung, die Schwie- 
rigkeiten bei der Portierung einer Macintosh-Anwendung auf den 
PC und die Organisation und Zusammenarbeit des Teams. 


Die Windows-Utility FreeMem zeigt in einem Sinnbild am unte- 
ren Rand des Windows-Bildschirms die Größe des verfügbaren 
Speichers an. FreeMem kann bei der Programmentwicklung unter 
Windows sehr nützlich sein. 


Zahlreiche wichtige Firmen unterstützen TIFF, ein neues Datei- 
format für den Grafikaustausch. Es sieht so aus, als ob TIFF damit 
zum zukünftigen Standard werden wird. 
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GPI: Eine Einführung in 
Präsentationsbereiche 





Koordination von Threads 
mit Semaphoren ... 





Die Grafikprogrammierschnittstelle von OS/2 (GPI: Graphics 
Programming Interface) ist neu auf PCs. Diese Kombination aus 
den besten Eigenschaften von IBM-GDDM, IBM-GCP und 
Microsoft Windows bietet einige sehr wichtige Erweiterungen 
gegenüber dem Graphics Device Interface (GDI) von Windows. 


Die OS/2-Semaphore sind ein leistungsfähiger Mechanismus, um 
mehrere gleichzeitig ausgeführte Threads zu koordinieren, Signale 
zwischen ihnen zu senden und den geregelten Zugriff auf Ressour- 
cen zu verwalten. 





QuickBASIC 








Terminalemulation mit QuickBASIC ..... 


Dieser Artikel beschreibt die strukturierte Programmierung in 
BASIC am Beispiel einer ADM3A-Emulation. Dabei wird auch 
näher auf die Threaded-P-Code-Technologie von Microsoft und 
ihre Bedeutung für zukünftige Entwicklungen eingegangen. 





Microsoft C und QuickC 





Dynamische Speicherverwaltungs- 
techniken .. 





Steve Schustak, der Autor von »Variationen in C«, gibt Tips und 
Hinweise zur dynamischen Speicherverwaltung in C. Besonders 
eingehend wird dabei auf verkettete Listen und die Speicher- 
verwaltungsfunktionen eingegangen. 





Assembler 





Ihr erster MS-DOS Gerätetreiber .. 





Wer glaubt, daß die Programmierung eines Gerätetreibers eine zu 
schwierige Angelegenheit ist, hat unrecht, wie diese Programmier- 
Anleitung für das Erstellen von MS-DOS-Gerätetreibern zeigt. 
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Programmentwicklung für Windows: 





Ein Interview mit den Excel-Entwicklern 


Bei der Umsetzung von Microsoft Excel in die 
PC-Umgebung bedurfte es größerer Anstrengun- 
gen, als bei einer einfachen Portierung der Mac- 
intosh-Version. Das Projekt-Team wollte eine 
Tabellenkalkulation entwickeln, die ein voll- 
kommen geräteunabhängiges, grafikorientiertes 
Produkt ist und nicht nur das Aussehen und die 
Bedienung der Macintosh-Version haben, son- 
dern auch wesentliche Verbesserungen in punkto 
Geschwindigkeit und Funktionalität bieten soll- 
te. Um diese Ziele zu erreichen, wurde die Kal- 
kulation für die Windows-Umgebung komplett 
neu geschrieben. 


Microsoft System Journal sprach mit dem Entwicklungs- 
team, um mchr über die Planung, die Entwicklung und ihre 
gemeinsamen Anstrengungen zu erfahren, die sie bei dieser 
komplexen Arbeit der Entwicklung von Microsoft Excel 
aufwenden mußten. 


MSJ: Was waren die eigentlichen Ziele beim Microsoft- 
Excel-Projekt? Wie wurden sie formuliert und in welcher 
Weise waren sie einzigartig für dieses Projekt? 

Das eigentliche Ziel war die Portierung der Macintosh- 
Version von Microsoft Excel nach Windows. Wir sahen, daß 
wir auf dem Macintosh ein fantastisches Produkt hatten und 
wollten es unter einer ähnlichen grafischen Benutzerschnitt- 
stelle auf dem PC zum Laufen zu bringen. 

Als Teil der Formulierung der Projektziele versuchten 
wir, die besonderen Anforderungen der PC-Benutzer zu 
verstehen. Wir achteten vor allem auf Fähigkeiten, die in 
vorhandenen Tabellenkalkulationen wie Lotus 1-2-3 vor- 
handen sind und wollten sicherstellen, daß unsere Software 
mindestens kompatibel bzw. konsistent mit diesen Fähig- 
keiten wird. Dann fügten wird die weiteren Fähigkeiten 
hinzu, die die Mac-Version zu einem so großen Erfolg ge- 
macht haben. 


MSJ: Microsoft Excel wurde für Microsoft Windows ent- 
wickelt. In welchen Bereichen war Windows dem Projekt för- 
derlich, in welchen hinderlich? 

Windows war dem Projekt ganz eindeutig förderlich, da 
es die grafische Umgebung bietet, die Microsoft Excel 
benötigt. Windows ist eine vollständige, Bitmap-orientierte 
und schr gut unterstützte Umgebung, die geräteunabhän- 
gige Treiber für all die verschiedenen Geräte beinhaltet, die 
in der PC-Welt existieren. Aus dieser Sicht betrachtet hät- 
ten wir Microsoft Excel ohne ein Produkt wie Windows gar 
nicht entwickeln können: Der erforderliche Mehraufwand, 
der für eine so leistungsfähige Umgebung wie Windows 
erforderlich ist, hätte das Projekt unmöglich gemacht. 
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Bild 1: Das Hilfe-Menü bietet den Benutzern detaillierte 
Unterstützung, zum Beispiel ein umfangreiches Glossar für 
alle Kalkulationsbegriffe, ein komplettes Online-Referenz- 
handbuch (wie es hier zu sehen ist), Tastaturübersichten und 
ein interaktives Online-Lernprogramm. 





Windows war insofern hinderlich, als es eine schr 
komplexe Umgebung ist. Teilweise liegt das daran, daß die 
PC-Welt selbst so komplex ist - die Anzahl der Geräte, die 
unterstützt werden müssen und die Probleme, die sich 
durch die Geräteunabhängigkeit ergeben, machen die PC- 
Welt schwieriger als die Apple-Welt. 


MS): Microsoft Excel läuft unter Windows 2.0, Win- 
dows/386 und bald auch unter OS/2. Was mußte berück- 
sichligt werden, um die Langlebigkeit und Portabilität des 
Programms sicherzustellen, und wurde die Aufgabe dadurch 
schwieriger? 

Es ist einfach so, daß die Macintosh-Umgebung sich von 
der Windows-Umgebung unterscheidet und diese wieder 
anders ist, als die Presentation-Manager-Umgebung. Häufig 
erkennt man diese Unterschiede erst, wenn man wirklich 
damit zu tun hat, wie das bei diesem Projekt der Fall war. 
Wir haben bei der Umsetzung vom Macintosh nach Win- 
dows eine Menge gelernt, was das Verständnis von 
Microsoft Excel angeht, und wie wir es noch umgebungs- 
unabhängiger machen können. Wir haben Dinge gelernt, 
die wir niemals erwartet haben, als wir die Portierung nach 
Windows begannen. 

Wir verwenden bei der Portierung von einer Umgebung 
in eine andere ein Konzept, daß wir »Kerncode« nennen. 
Das bedeutet, es wird so viel wie möglich herausgenommen, 
was nicht umgebungsspezifisch ist. Dann nimmt man den 
umgebungsabhängigen Code und versucht, das zu isolieren, 
was in den Umgebungen verschieden ist und stellt fest, wie 
der Code so angepaßt werden kann, daß er von beiden ver- 
wendet werden kann. 
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Bild 2: Microsoft Excel bietet einen umfangreichen Satz an 
Tools, die dazu verwendet werden können, ausgefeilte Kalku- 
lationsanwendungen und Berichte mit professioneller Qualität 
zu erstellen. 





Microsoft Excel wird bald auch an den Presentation 
Manager unter MS-OS/2 angepaßt werden. Der Presen- 
tation Manager unterscheidet sich ein wenig von Windows. 
Microsoft Excel wird so geändert werden müssen, daß diese 
Unterschiede unterstützt werden, aber es wird sicherlich 
problemlos laufen, wenn das erfolgt ist. Wir glauben, das 
nach der Implementierung in zwei Umgebungen die dritte 
wesentlich einfacher sein wird. 


MSIJ: Einige von Ihnen waren an der Entwicklung von 
Microsoft Excel für den Macintosh beteiligt. Was war der 
größte Unterschied des PC-Projekts und wie hat Ihnen die 
Mac-Erfahrung bei diesem Projekt genutzt? 

Der interessanteste Aspekt des PC-Projekts war die 
Änderung der Speicherverwaltung. Ein Grund dafür war, 
daß wir eine bessere Adressierbarkeit haben wollten, als wir 
sie auf dem Macintosh haben. Wichtiger jedoch war, wie 
man die bessere Adressierbarkeit in der PC-Welt realisie- 
ren kann - zur Zeit wird das in der Regel mit EMS-Karten 
durchgeführt. Gewöhnlich haben die Karten ein Speicher- 
fenster von 64 Kbyte und es können sich in einem Spei- 
cherfenster vier Seiten befinden. Aus Effizienzgründen 
sollte man die Seiten kleiner als 64 Kbyte halten. Meistens 
verwendet man eine Größe von etwa 16 Kbyte, damit man 
so viele wie möglich davon haben kann. Der ganze Entwurf 
der Datenstrukturen mußte geändert werden, um diese 
»Brocken« zu unterstützen. 


MS): Wie wurde das Microsoft-Excel-Projekt in einzelne 
Aufgaben aufgeteilt? 

Es wurde in einzelne Aufgaben aufgeteilt, indem 
Microsoft Excel für den Macintosh sorgfältig untersucht 
und ein Plan gemacht wurde, wie der existierende Code der 
Macintosh-Version nach Windows portiert werden könnte. 
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Bild 3: Die Makros automatisieren nicht nur wiederholte 
Arbeitsschritte (zum Beispiel mit dem Makro-Rekorder), son- 
dem ermöglichen auch die extensive eigene Gestaltung des 
Bildschirmaufbaus. 


Es waren eine ganze Reihe von erfahrenen Leuten 
daran beteiligt - Leute, die schon an der Macintosh-Ver- 
sion mitgearbeitet hatten und die eine Menge von grafi- 
schen Benutzerschnittstellen und Umgebungen verstehen. 
Im wesentlichen verteilten wir die Bereiche nach der Erfah- 
rung, die die Leute hatten. Die Diagramme wurden zum 
Beispiel jemand gegeben, der genau versteht, wie das in der 
Mac-Umgebung funktioniert und der bei den Änderungen 
für Windows sogar ein noch größerer Experte wurde. 





MSJ: Was ist Ihrer Meinung nach die ideale Größe für ein 
Projekt-Team? 

Die Teamgröße lag zwischen 8 und zehn Leuten. Irgend- 
wann über zehn Leuten wird ein Projekt zu groß: Es ent- 
wickeln sich Kommunikationsprobleme und der Durchsatz 
wird geringer. Je mehr Leute damit befaßt sind, desto mehr 
Zeit bringt man damit zu, sie über Änderungen zu informie- 
ren und sicherzustellen, daß jeder versteht, was die anderen 
machen. Wir ziehen es vor, Projekt-Teams unterhalb dieser 
Zehn-Leute-Grenze zu haben. Wenn wir das nicht können, 
verwenden wir separate Unterprojekte und erstellen sehr 
gute, sauber definierte Schnittstellen zwischen den Unter- 
gruppen, so daß es nicht erforderlich ist, daß sie stark 
miteinander zu tun haben. 


MSIJ: Erzählen Sie uns etwas über die Geheimnisse und 
Strategien, die sicherstellten, daß das Projekt gelang. 

Unsere Strategie besteht darin, daß wir den Einzelnen 
viel Verantwortung übertragen, so daß sie sich persönlich 
an dem beteiligt fühlen, was sie tun und daß sie wirklich 
stolz auf das sind, was sie geschaffen haben. Wir machen 
hier keine Vorschriften, die regeln, wie die Leute Probleme 
zu lösen haben und bestehen nicht auf Entwürfen, die sie zu 
implementieren haben. 
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Bild 4: Die insgesamt 44 verschiedenen Grafiktypen bieten 
eine große Flexibilität. Diagramme können nach individuellen 
Erfordernissen modifiziert und für Vergleiche auch neben- 
und übereinander gelegt werden. 


Es ist mehr so, daß die Leute zu Experten in Ihrem 
Bereich werden und dann selbst die Initiative übernehmen. 
Sie sind auch dafür verantwortlich, daß eine Lösung 
gefunden wird und daß alles innerhalb vernünftiger Zeiten 
geschieht. 

Ein wichtiger Teil davon ist, daß die Team-Mitglieder 
am Entwurf und der Planung des Projekts teilhaben. Sie 
übernehmen die Verantwortung für das, was sie tun und wie 
lange sie dafür brauchen; es ist ein Bottom-Up-Entwurf. 
Jemand analysiert sorgfältig die notwendige Arbeit und ver- 
pflichtet sich dann, diese Arbeit durchzuzichen. 


MSJ: Ganz offensichtlich haben Sie dafür gesorgt, daß 
Anwender von Lotus 1-2-3 einen leichten Übergang nach 
Microsoft Excel haben. Haben Sie andere Zugeständnisse 
machen müssen, um Lotus-Benutzern entgegenzukommen? 

Wir haben eine sorgfältige Analyse der Fähigkeiten von 
Lotus 1-2-3 Version 2 durchgeführt. Wir haben dafür 
gesorgt, daß die Funktionalität komplett vorhanden ist, so 
daß Lotus-Benutzer nicht glauben, irgendetwas aufgeben zu 
müssen, das für sie nützlich ist. Die Entwicklung des 
Makro-Umsetzers war eine schr umfangreiche Aufgabe. 
Die Makrosprache von Microsoft Excel arbeitet total 
anders als die 1-2-3-Makros, denn wir verwenden nicht 
Tasten als Grundlage. Wir haben die Lotus-Schnittstelle 
auch nicht direkt umgesetzt, wie das andere Produkte 
machen. Wir wollten ein intelligentes Programm haben, das 
die Makros analysieren und feststellen kann, was die Ab- 
sicht des Lotus-Makros ist und es dann in die gleiche Art 
Makros für Microsoft Excel umsetzt. 

Wenn es den 1-2-3-Standard nicht gegeben hätte, hätten 
wir einige Dinge sicherlich anders gelöst - auf Arten, die 
wir für effizienter und gelungener halten. Lotus 1-2-3 ist 
nun mal in den USA ein Standard. 
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Bild 5: Die Windows-Umgebung erhöht die Vielseitigkeit von 
Microsoft Excel, da der Benutzer Grafiken und Tabellen aus 
Microsoft Excel in andere Anwendungen (z.B. Write) inte- 
grieren kann. 


Da sehr viele Leute 1-2-3 kennen und damit umgehen 
können, mußten wir uns irgendwie an diesen Standard 
halten. Wir konnten also nicht alle Fähigkeiten so imple- 
mentieren, wie wir es gerne getan hätten. 


MSJ: Wie wichtig war bei diesem Projekt die Devise 
»Mach’ es schneller«? Wie haben Sie festgestellt, daß das Pro- 
gramm schnell genug ist? 

Die Geschwindigkeit ist bei Tabellenkalkulationen sehr 
wichtig. Das haben wir von Microsoft Excel für den Maecin- 
tosh gelernt haben; sie ist einer der Gründe dafür, daß das 
Programm so gut angekommen ist. Wir haben uns sehr 
stark auf die Geschwindigkeit konzentriert und die Benut- 
zer meinten, daß das Programm das ist, was wir »knackig« 
nennen. Es reagiert schnell auf das, was sie tun wollen. 

Deshalb haben wir die Geschwindigkeit bei Microsoft 
Excel zur Aufgabe mit höchster Priorität gemacht. Das 
führte dazu, daß wir sehr ausführliche Benchmarks mit vor- 
handenen Programmen und Microsoft Excel für MS-DOS 
angestellt haben, während wir es erstellten. Jedesmal, wenn 
wir eine Testversion fertig hatten, haben wir alle 
Benchmarks wieder laufenlassen. Wenn irgendetwas lang- 
samer wurde, haben wir schnell herausbekommen, woran es 
lag. Mit den Benchmarks haben wir uns Ziele gesetzt; die 
regelmäßige Verwendung ermöglichte es uns, diese Ziele zu 
erreichen. Wir verwendeten so viel wie möglich bestehende 
Entwürfe, um auch noch das letzte Bißchen Geschwindig- 
keit herauszuquetschen, ohne irgendetwas wegzuwerfen. 
Dies macht man, indem man Benchmarks durchführt, die 
vermutlich langsamen Teile herausfindet und dann eine 
detaillierte Analyse mit Profilern durchführt. Durch diese 
Analyse kann man herausfinden, was langsam ist. Man kann 
dann entscheiden, ob man einen begrenzten Neuentwurf 
macht oder nur besseren Code für diesen Bereich schreibt. 











Bild 6: Microsoft Excel kann mit dem interaktiven Lernpro- 
‚gramm leicht erlemt werden. Es analysiert die Benutzerein- 
gaben und stellt sicher, daß die richtigen Arbeitsabläufe 
befolgt und die korrekten Antworten gegeben werden. 


In einer grafischen Umgebung sind die Bereiche, die 
langsam sind, nicht die, die die Neuberechnung durch- 
führen. Was langsam ist, ist die Bildschirmausgabe - ganz 
einfach die Bewegung all der vielen Bits. Wir haben erheb- 
liche Zeit damit zugebracht, zu verstehen, wo die Zeit bei 
der Bildschirmanzeige verschwendet wird. Wie sich zeigte, 
wird ein hoher Prozentsatz der Zeit beim Scrollen damit 
verbracht, die Bits auf dem Bildschirm von einer Stelle zur 
anderen zu verschieben. Der Grund dafür liegt darin, daß 
die EGA-Karte, die unter anderem von uns unterstützt 
wird, eine Menge Wait-States benötigt. Es wird eine Menge 
Zeit dafür benötigt, eine Bit-Spalte zu verschieben, ganz 
einfach weil die EGA-Karte so langsam ist. Wir kennen die 
Karte nun genau und haben viel Zeit darauf verwendet, die 
Bildschirmausgabe so schnell wie möglich zu machen. 


MSJ: Unter anderen Neuheiten bietet Microsoft Excel 
auch das Windows-DDE-Protokoll (Dynamic Data Ex- 
change). Wie schwierig war dieser Teil des Projekts und was 
haben Sie dabei über die Implementierung von DDE gelernt? 

Im Prinzip war DDE sehr einfach. Wir machten einen 
Entwurf, beschrieben, was wir dafür benötigten und schaff- 
ten es, mit einer Untermenge von neun Befehlen auszu- 
kommen, die alles machen, was wir brauchen. 

Andererseits war die Implementierung sehr schwierig. 
Da DDE ein asynchrones Kommunikationsprotokoll ist, 
muß das Produkt Meldungen jederzeit bearbeiten können, 
ganz gleich, was das Produkt gerade macht. Das macht es so 
komplex. Microsoft Excel war ursprünglich nicht so 
konzipiert, daß es Meldungen zu jeder beliebigen Zeit 
bearbeiten kann. Wir mußten genau analysieren, wie wir 
diese Fähigkeit implementieren konnten. 

Wir mußten Entwurfsänderungen vornehmen, um Mel- 
dungen in eine Warteschlange zu stellen oder um sie zu 
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Bild 7: Ein Fehler des Benutzers führt dazu, daß das Lernpro- 
gramm Tips gibt und so dem Benutzer die Gelegenheit gibt, 
die Antwort noch einmal zu überdenken und eine neue Ant- 
wort einzugeben. 


bearbeiten, während das Programm sich in der Makrospra- 
che befindet, gerade eine Neuberechnung durchführt oder 
andere zeitintensive Arbeiten durchführt. Die Implementie- 
rung dauerte wesentlich länger als wir erwartet hatten, doch 
rückblickend muß ich sagen, daß das daran lag, daß wir 
nicht von vorneherein alle Dinge berücksichtigten, die zur 
Unterstützung dieses Protokolls notwendig sind. 


MSJ: Das Microsoft-Excel-Projekt benötigte drei Jahre. 
Wie wichtig war die Stimmung der Gruppe in dieser Zeit? 

Sehr wichtig. Man kann keine derart großen und kom- 
plexen Projekte durchziehen, ohne daß die Leute motiviert 
sind und sich in gewissem Sinne als Schöpfer fühlen. Wir 
haben bei all unseren Projekten immer eine schr gute 
Stimmung gehabt, weil die Leute fühlen, daß es ihre Arbeit 
ist, die da gemacht wird. 

Teilweise beruht die gute Stimmung darauf, daß die 
Leute, die den Code schreiben, auch verstehen, um welche 
Features es geht. Die Features werden nicht von jemand 
vorgeschrieben der Spezifikationen schreibt und der sagt: 
»Und jetzt führen wir das aus.« Die Entwicklungsgruppe ist 
aktiv an der Analyse der Features beteiligt. Sie versuchen zu 
verstehen, was wir erreichen wollen, machen Vorschläge 
und sagen, was sie für gut halten und was nicht. 

Jemand der die falsche Arbeit macht, weiß das in der 
Regel. Es ist sehr selten, daß jemand für sechs Monate in 
der falschen Position gewesen ist und man dann zu der Per- 
son sagt: »Das ist scheußlich.« Stattdessen wird auf dem 
ganzen Weg eine leitende Hand geboten. Das hilft den 
Qualm zu vertreiben, wenn es einmal zu viel geworden ist: 
zeigen, was wichtig ist, vielleicht auf eine bessere Lösung 
hinweisen oder auch empfehlen, einen Schritt zurückzuge- 
hen und darüber nachzudenken, was bisher gemacht wurde, 
bevor weitergemacht wird. 


Juli/August 1988 Microsoft System Journal 7 








Bild 8: Selbst wenn Excel nicht in der Windows-Umgebung 
läuft, bietet es umfangreiche Fenster-Möglichkeiten. Hier sind 
zwei Diagramme und die zugrundeliegenden Tabellen zu 
‚sehen, die verschiedene Ansichten derselben Daten zeigen. 


Die Leitung eines Projekts ist eine interessante Arbeit, 
vor allem unter dem Gesichtspunkt, daß sie unter- 
brechungsgesteuert ist. Bei der Erfahrung und dem Wissen, 
daß unser Projekt-Team hat, brauchen wir ihnen nicht 
genau zu sagen, wie sich das Projekt entwickeln soll. Wir 
brauchen nur zuzuschauen und uns ihre Entscheidungen 
anschen. Wir können dann hergehen und sicherstellen, daß 
nicht einer zu wenig ist oder - was häufiger vorkommt - 
daß eine andere Gruppe etwas entdeckt hat, was zwischen 
den Gruppen vermittelt werden muß. Sie müssen verstehen, 
daß wenn eine Gruppe Probleme mit den Ressourcen hat, 
wir diese Ressourcen beschaffen können. Wenn wir die 
Planung ändern müssen, schen wir warum und es wird dem 
Projekt-Team mitgeteilt. 


MSJ: Gibt es eine Phase bei diesem Projekt, die sich als 
besonders schwierig herausstellte? 

Die schwierigste Phase ist, keine falsche Hoffnungen zu 
wecken. Es besteht zu Beginn eines Projekts die Tendenz, 
so viel wie möglich zu machen. Wenn man das Produkt 
auch ausliefern will, muß man das mit der verfügbaren Zeit- 
spanne in Einklang bringen. Die Entwicklung von Microsoft 
Excel ist nicht beendet. Wir haben noch Hunderte von 
Features, die wir in das Produkt hineinstecken möchten. 

Ein Teil des Jobs bestand darin, sich die lange Liste der 
möglichen Features anzusehen und zu sagen: »Das ist heute 
nicht wichtig..., aber das.« Das ist der bei weitem schwierig- 
ste Teil des Jobs, sicherzustellen, daß man das richtige tut 
und das Team auf realistische Ziele ausrichtet. 


MSJ: Hat es irgendwelche Features gegeben, die außer 
Kontrolle gerieten? 

Es gab eigentlich nichts, was außer Kontrolle geriet, 
denn wir hatten den Vorteil, das erfahrene Leute an diesem 
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Bild 9: Die Diagramme können vom Benutzer in vielen 
Einzelheiten durch selbstgewählte Farben, Ränder, Schattie- 
nungen, Schriftarten und Legenden individuell angepaßt wer- 
den. 


Projekt arbeiteten. Sie haben schon gesehen, was es be- 
deutet zu sagen: »Oh, das ist doch einfach« und dann acht 
mal länger als erwartet dafür zu benötigen. Es besteht die 
Tendenz zu einer ausführlicheren Analyse und dem Ver- 
ständnis, worum es geht, bevor man sich auf etwas einläßt. 


MS): War die Nähe von zwei anderen Gruppen, der Win- 
dows- und der OS/2-Gruppe, für die Entwicklung von Excel 
hilfreich? 

Es war aus mehreren Gründen sehr hilfreich, die Win- 
dows-Gruppe in der Nähe zu haben. Zunächst einmal 
ermöglichte es uns, über die Schnittstellen zu diskutieren. 
Einige der Änderungen, die für Windows 2.0 durchgeführt 
wurden, sind das Ergebnis von notwendigen Änderungen 
der Schnittstelle. Das Multiple Document Interface (MDI) 
ist ein Ergebnis der Arbeit von uns und anderer unabhängi- 
ger Softwareentwickler. Wir hielten sie für notwendig, um 
den Bildschirmbereich für den Benutzer maximal auszunut- 
zen. 

Wir konnten das Design von Windows auf ähnliche 
Weise beeinflussen, wie wir auf die Macintosh-Schnittstelle 
einwirken konnten. Wir waren aktiv an der Entwicklung 
komplexer Produkte beteiligt und hatten viele Tips, wie 
man es besser machen konnte. Die Tatsache, daß sie sich 
»auf der anderen Seite des Ganges« befanden, war nicht so 
wichtig - wir hätten es auch über Telefon oder mit Besu- 
chen erledigen können, wie wir das bei Apple gemacht 
haben. 

Die Nähe half uns jedoch, Fehler aufzuspüren. Wir 
konnten der Windows-Gruppe helfen. Wenn wir auf einen 
Fehler stießen und glaubten, daß er sich in ihrem Code be- 
findet, konnten wir ihn isolieren und einen Windows- 
Experten kommen lassen, der es sich ansah und das Pro- 
blem ausfindig machen konnte. 





Bild 10: Man kann sich ein Diagramm oder eine Tabelle vor 
dem Ausdruck ganzseitig ansehen. Die Lupe ermöglicht es 
dem Benutzer, sich beliebige Bereiche der Seite vergrößert an- 
zusehen. 


Das hat sich mehr als alles andere ausgezahlt, daß wir 
uns den Code ansehen konnten und Hilfe hatten und 
natürlich die Kommunikation zwischen beiden Gruppen. 


MS]: Welche Rolle spielte Bill Gates bei der Entwicklung 
von Microsoft Excel? 

Bill war der Weitsichtige. Er ist einer von den Leuten, 
die wirklich sagen können: »Wir brauchen ein Feature wie 
dieses, das ist schr wichtig.« Er war an dem beteiligt, was 
aus dem Produkt wurde, weil er sehr viel Überzeugungs- 
kraft hat und seine Ideen gut an andere weitergeben kann. 

Wir haben jetzt so lange mit Bill zusammengearbeitet, 
daß wir nun viele derselben Fragen stellen können, die Bill 
stellen würde. Wir können den richtigen Entwurf machen, 
weil wir kritischer mit uns sind. Bill hat uns im Laufe der 
Zeit gezeigt, daß wir nicht selbstzufrieden sein und mehr 
über das nachdenken sollten, was wir tun. Wenn wir eine 
Besprechung hatten, stellte er Fragen, die wir dumm 
fanden, weil wir keine Antworten darauf hatten. Wir haben 
nun genügend ähnliche Situationen erlebt, so daß wir uns 
heute dieselben Fargen stellen und sie beantworten können, 
bevor wir in cine Besprechung gehen. 












































Bild 11: Mit der Zoom-Möglichkeit kann der Anwender jede 
Einzelheit eines Diagramms oder einer Tabelle untersuchen. 
Wenn »Zoom« angeklickt wird, wird zwischen verkleinerter 
und vergrößerter Darstellung umgeschaltet. 


MSJ: Gibt es rückblickend etwas, was Sie heute anders 
machen würden? 

Es wäre schön gewesen, wenn einige Dinge reibungs- 
loser abgelaufen wären, doch es gibt eigentlich nichts, was 
wir anders machen würden. Dieses Projekt wurde mit eini- 
gen neuen Philosophien und neuen Vorgehensweisen für 
die Entwicklung organisiert. Während die Entwicklung 
nicht immer so reibungslos verlief, wie wir das gehofft hat- 
ten (ganz einfach weil das meistens so ist), verlief sie doch 
genauso, wie wir hofften, wenn man sich das Ergebnis 
ansicht und wie das Projekt gemanaget wurde. Wir werden 
weiter an dieser Vorgehensweise arbeiten. 


MSJ: Wie fühlt sich die Gruppe jetzt, wo eine neue Vari- 
ante von Microsoft Excel auf dem Markt ist? 

Die ist erst der Beginn von Microsoft Excel. Wir haben 
gesehen, wie es auf dem Macintosh aussieht und wir haben 
gesehen, wie es unter Windows aussieht. Noch wichtiger, 
wir haben so viele Ideen und so viele Neuheiten, die wir 
implementieren möchten, daß es eigentlich so aussieht, wie 
der Anfang einer langen Geschichte ausgezeichneter Tabel- 
lenkalkulationen. 
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Fragen & Antworten 


DEUTSCHE 
URAUFFUHRUNG! 


Die maximale Baudrate 
des Windows-COM-Treibers 


F: Kann der COM-Treiber von Win- 
dows 2.03 auf 19200 Baud eingestellt 
werden? 


A: Der Windows-Gerätetreiber unter- 
stützt 19200 Baud und überträgt Daten 
mit dieser Rate. Doch wird die CPU 
selbst wahrscheinlich die Daten nicht 
übertragen können, der Durchsatz 
liegt also mehr im Bereich 9600 Baud. 


Prüfsummenberechnung für 
den Header einer PAINT-Datei 


F: Das Dateiformat von Microsoft 
Windows Paint enthält im Header ein 
Feld mit dem Namen wCheck, daß 
eine Prüfsumme enthält. Wie wird sie 
berechnet? 


A: Die ersten 12 Worte im Header 
werden mit XOR verknüpft um die 
Prüfsumme zu erhalten. Eine Methode 
zur Berechnung der Prüfsumme kann 
so aussehen: 





WORD pfilehdr; 
FILEHDR filehdr; 


/" Auf das erste Wort initialisieren #/ 
filehdr ‚vCheck = filehdr.keyl; 


pfilehdr = &ftlehdr.key2; 
Tor (i=1; 1 € 12; 1®+) 
filehdr.vcheck “= "pfilehär++; 











Ein Zeiger auf den Stack 


F: Wie kann ich einen Zeiger auf den 
Stack erhalten? 


A:c pusht seine Parameter in umge- 
kehrter Reihenfolge. Der erste Para- 
meter ist immer der zuletzt gepushte, 
ist immer oben auf dem Stack und hat 
immer die selbe Adresse relativ zum 
Beginn der Parameter. Sie können die 
Stackadresse so festzustellen: 








far foo() 
Int x; 


int far #y = ix; 
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MICROSOFT EXCEL ODER 
DIE LIEBE ZUR 
TABELLENKALKULATION. 


1. Aufzug, 1. Szene: Anwender, Entscheider, PC 
und Microsoft Excel. 


‚Anwender (enttäuscht): Grau, teurer Freund, ist alle Theorie... 
PC (hoffnungsvolj: Nicht doch, sieh‘, hier naht Microsoft Excel 
schon. Das bringt Akton in die Tabellen- 
kalkulation. 
Microsoft Excel: Kompetent, intelligent und exzellent, Tabellonkalkuls- 
steh‘ ich fürs Zahlenmanagement. tion mit Graphik- 
Arbeie heute auf Microsoft und Datenbank- 
WINDOWS 2.0 und 386 - morgen, funktionen - Ma- 
bite sehr, für den Presentaton kroprogrammier- 
Manager. Biete dynamischen Daten- *prachen - Kon- 
austausch und stehe zur Disposition ee E 
gleichzeitig für viele Tabellen bis hin 
zur 3. Dimension. 
‚Anwender (beeindruckt): Und wie haltet Ihr's mit Applikation? aussetzungen: 
Microsoft Excel: Meine Makros machen mich beweg- WINDOWS 2.0/ 
lich und dadurch einfach alles möglich. u aa 
Allerorten - in deutschen und in ganzen wi 
Worten. 
Anwender (erstaunt): 286/386 Prozessoren? Problembezogene 
Menüs und Dialogboxen? Makrorekorder, ver- 
schiedene Schriftiypen? Übersezung von 
Tabellen, Makros und 1-2-3-Befehlen? 
Microsoft Excel: ‚Aber ja, was soll die Frage? Mache jeden 
‚Auftrag ohne Klage. 
‚Entscheider (überzeugt): Diese weiten Möglichkeiten, was für Zeiten, was 
für Zeiten. Tabellenkalkulation für jeden Zweck. 
Formatieren, gestalten, drucken, präsentieren. 
Funktionen für Grafik und Datenbank. Gestal- 
tungsmöglichkeiten in Farbe. Fürwahr, fürwahr, 
ich sehe die Entscheidung klar. Schluß jetzt mit 
den Unklarheiten, und auf in neue große Zeiten. 
Microsoft Excel: Die Zukunft ists, für die ich stehe. Daß Zukunft 
heute schon geschehe. 


Vorhang/Frenetischer Beifall 
as/nes) [CRT, (me [640/uR) 226/356) 


Microsoft 


ZUKUNFT DER SOFTWARE 


























couPpoNn 
Bitte senden Sie mir Informationsmaterial zu Microsoft Excel. Ich nutze Software: L] privaı 
D beruflich/Branche 
Mein Rechner: DMS-008 DIMS-0S/2 DJ Maciniosh 


Bitte senden Sie den Coupon an: Microsoft GmbH + Erdinger Landstraße 2 + BOT Aschheim-Domach 
Absender nicht vergessen. 








Fragen & Antworten 


Interrupte unter Windows 


F: Welche Interrupte werden von Win- 
dows abgefangen, welche werden ver- 
wendet? 


A: Windows fängt folgende Interrupte 
ab: 


1. Interrupt 21h: Jeder Funktionsauf- 
ruf, der mit Zeichen-Ein-/-ausga- 
ben nach STDIN, STDOUT und 
STDERR zu tun hat, z.B. IOCTL, 
OPEN, READ, WRITE usw. 

2. BIOS-Interrupt 10h: Jede Funk- 
tion, die mit Zeichen-Ein-/-aus- 
gabe zu tun hat. Teilweise 
TOPVIEW-Emulation. 

3. Interrupt 20h, 21h, 24h: Jede 
Funktion, die mit EXEC, ALLOC 
und REALLOC zu tun hat. 


Windows verwendet nur den Inter- 
rupt 3Fh, der Interrupt für dynami- 
sches Linken. 


Windows direkt verlassen 


F: ıst es für eine Anwendung unter 
Windows möglich, eine Meldung an 
Windows zu schicken, die besagt, daß 
die Anwendung und Windows beendet 
werden sollen? 

A: Diese Möglichkeit wird für die 
aktuellen Versionen von Windows von 
Microsoft nicht unterstützt. Die fol- 
genden Anweisungen scheinen jedoch 
zu funktionieren und alle Vektoren 
wiederherzustellen: 





DisabledenLayer(); 
ExttKernel($): 








Eine bessere Methode besteht 
darin, dem MS-DOS Executive mit 
PostMessage die Meldung WM_SYS- 
COMMAND zu schicken. Der Parameter 
wParam dieser Meldung sollte der 
vordefinierte Wert SC_CLOSE sein. 
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Windows-Utility FreeMem: 


Anzeige des freien Speichers unter Windows 


Für Programmierer, die sich das erste Mal mit 
Microsoft Windows auseinandersetzen, scheinen 
sogar einfache, nichts ausführende Windows- 
Programme unglaublich lang und komplex zu 
sein, Sie werden glauben, daß alle Windows-An- 
wendungen monströse Ansammlungen von Pro- 
grammzeilen sind. Das ist natürlich nicht wahr. 


Nehmen Sie das Programm FreeMem, ein komplettes und 
nützliches Microsoft Windows-Programm mit weniger als 
100 Zeilen C-Quellcode. Das Programm FreeMem zeigt in 
einem Sinnbild am unteren Rand des Windows-Bildschirms 
die Größe des verfügbaren Speichers an. Der Wert des 
freien Speichers wird jede Sekunde aktualisiert und stimmt 
mit dem in der About-Box im MS-DOS-Fenster angezeig- 
ten Wert überein. 

Die Kürze von FreeMem hilft die Struktur von Win- 
dows-Anwendungen verständlicher werden zu lassen, und 
erlaubt die ausführliche Diskussion einiger Programmier- 
details unter Windows. Da FreeMem ein ungewöhnliches 
Windows-Programm ist, untersuchen wir auch einige seiner 
Tricks. 


Gesamtstruktur 


FREEMEM.C enthält nur zwei Funktionen: WinMain 
(Listing I) und WndProc (Listing 2). Ähnliche Funktionen 
finden Sie in den meisten Windows-Anwendungen. 

WinMain ist der Eintritt zu FreeMem. WinMain führt 
hauptsächlich alle Initialisierungen durch, die zum Erzeu- 
gen und zum Anzeigen des Fensters notwendig sind. 

Die an die Funktion RegisterClass übergebene 
Struktur WndClass definiert die Fensterklasse. Der wich- 
tigste Teil der Struktur WndClass ist IpfnWndProc, wel- 
cher die Funktion innerhalb von FreeMem angibt, die die 
Nachrichten von Microsoft Windows bearbeitet. Dies ist die 
Funktion WndPr.oc, die Sie im Listing 2 sehen. 

Die Funktionen CreateWindow, ShowWindow und 
UpdateWindow veranlassen alle Fenster zum Senden von 
Nachrichten an die Funktion WndProc. Innerhalb der 
Funktion WndProc werden diese Nachrichten durch 
Namen, die mit WM beginnen, identifiziert. Diese Namen 
sind einfache Makrobezeichner, die in der Header-Datei 
WINDOWS.H enthalten sind, und zum leichteren Verständnis 
die Angabe von Zahlencodes überflüssig machten. 

WndProc unterscheidet die Nachrichten durch eine 
case-Anweisung. Nur einige der von Windows gesendeten 
Nachrichten werden von WndProc direkt bearbeitet. Die 
restlichen werden an die in Windows enthaltene Funktion 
DefWindowProc weitergeleitet, wo eine Standardbearbei- 
tung stattfindet. 
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Bild 1: Die Windows-Utility FreeMem. 


CreateWindow veranlaßt Microsoft Windows, die Nach- 
richt WM_CREATE zu erzeugen. ShowWindow erzeugt in der 
Regel eine ganze Anzahl von Nachrichten, darunter auch 
WM_SIZE und WM_ERASEBKGND. Diese Nachrichten sind 
für das Darstellen des Fensters und das Löschen des 
Hintergrunds zuständig. Beim Aufruf der FreeMem-Funk- 
tion UpdateWindow erzeugt Microsoft Windows eine 
WM_PAINT-Nachricht, die WndProc auffordert, den Client- 
Bereich des Fensters darzustellen. 

Nach dem Aufruf von UpdateWindow verweilt Free- 
Mem in einer Nachrichtenschleife. Der Funktionsaufruf 
GetMessage erhält eine Nachricht von FreeMems Nach- 
richtenschlange. Sind keine Nachrichten für FreeMem vor- 
handen, kann die Kontrolle an eine andere Windows- 
Anwendung übergeben werden. Die derzeitige nicht zeit- 
scheibengesteuerte Ausführung von Windows garantiert, 
daß nur ein Aufruf von GetMessage die Ausführung von 
FreeMem unterbrechen kann. FreeMem erhält die Kon- 
trolle wieder, wenn einige Nachrichten in seiner Schlange 
sind und die Schlangen der anderen Anwendungen leer 
sind, In Wirklichkeit ist dieses Thema ein wenig komplexer, 
aber ich werde es später ausführlicher erörtern. 

TranslateMessage übersetzt Tastendrücke in Zei- 
chencode-Nachrichten. Obwohl sich FreeMem nicht um 
Tastendrücke kümmert, ist diese Schnittstelle notwendig für 
das System-Menü von FreeMem. DispatchMessage sen- 
det die Nachrichten dann an die Funktion WndProc. 

FreeMem ist beendet, wenn GetMessage eine Nach- 
richt WM_QUIT aus der Nachrichtenschlange erhält. Die 
Funktion GetMessage liefert in diesem Fall den Wert 0 
zurück, und FreeMem entfernt sich aus der Nachrichten- 
schlange. 

Soweit entspricht diese Funktion den meisten Windows- 
Anwendungen, aber schen wir uns die Details näher an. 


Windows 





Nützlicher Gebrauch der Sinnbilder 


Anders als bei den meisten Windows-Programmen ist bei 
FreeMem nur die Darstellung als Sinnbild beabsichtigt. 
Nach dem Start von FreeMem können Sie die Tastatur oder 
die Maus zum Öffnen des Sinnbilds in ein reguläres geteil- 
tes Fenster benutzen, aber Sie erhalten dadurch nicht mehr 
Informationen. 

Eine große Zahl Windows-Programme besitzt statische 
bildhafte Sinnbilder. Die Programmierer erzeugen diese 
Sinnbilder in der Regel mit dem Diensprogramm ICON- 
EDIT, das im Microsoft Windows Software Development 
Kit enthalten ist. Die Sinnbilddatei (. CO) wird in der Res- 
sourcendatei durch einen Namen angegeben. Beim Erzeu- 
gen der Fensterklasse wird das Sinnbild durch das State- 
ment 











[ernennen = Loadicon(hinstance, (LPSTR)szAppName) ; 


angegeben. Die Funktion LoadIcon lädt das Sinnbild aus 
dem Teil der EXE-Datei, wo alle Ressourcen angesiedelt 
sind, und weist ihr eine Handle zu. (Ich setze hier voraus, 
daß das Sinnbild denselben Namen wie die Anwendung 
trägt, und daß szAppName ein Zeiger auf eine Zeichen- 
kette mit diesem Namen ist.) 

Wenn Sie statt dessen das Statement 





WndClass.hIcon = NULL; 











benutzen, dann ist die Anwendung selbst für das Dar- 
stellen des Sinnbilds zuständig. Das gibt Ihrer Anwendung 
die Möglichkeit, ein dynamisches Sinnbild zu erzeugen, das 
Sie ändern können, Die UHR-Anwendung in Microsoft 
Windows benützt dieselbe Technik, um die Zeit anzuzeigen, 
sogar dann, wenn das Fenster als Sinnbild dargestellt wird. 

Aus der Sicht des Programmierers ist ein NULL-Sinn- 
bild ein kleines Fenster, in das in derselben Art geschrieben 
werden kann, wie in den Client-Bereich eines normalen 
Fensters. Wenn Sie wissen müssen, wann Ihre Anwendung 
als Sinnbild dargestellt ist, können Sie diese Information der 
Nachricht WM_SIZE entnehmen. UHR wertet diese Ände- 
rung aus, kann so den Sckundenzeiger unterdrücken und 
aktualisiert die Darstellung in der Sinnbildform dann nur 
noch jede Minute. 


Sinnbilddarstellung erzwingen 


Um eine Windows-Anwendung im MS-DOS-Fenster zu 
starten, drücken Sie entweder die [Return)-Taste während 
der Cursor auf dem Programmnamen steht, klicken den 
Programmnamen zweimal mit der Maus an oder wählen 
File Run aus dem Menü. Wollen Sie statt dessen ein Pro- 
gramm als Sinnbild laden, so drücken Sie [Shift)[Return), 
wenn der Cursor auf dem Programmnamen steht oder 
wählen File Load aus dem Menü. 


























/® Freeiiem.C -- Windows-Anvendung,, 
die den freien Speicher anzeigt */ 


#include <windovs.h> /® Alle Windows-Funktionen ®/ 
#include <stdlib.h> /® Itoa #/ 
#include <string.h> /" streat und strlen #/ 


long FAR PASCAL WndProc(HWND, unsigned, WORD, LONG); 


int PASCAL WinMain(hinstance, hPrevInstance, 1pszCndLine, 
HANDLE hinstance, hPrevInstance; 
ei 4 ne; 
in r 


N h 
static char rererg = "Freellen"; 
WNDCLASS. ass; 

HWND hiind; 

NSG sg; 

if(hPrevInstance) 

return(FALSE); 


WndClass.hCursor = LoadCursor(NULL, IDC_ARROW); 

WndClass.hicon = NULL; 

WndClass.cbUlsExtra 
:biindExtra 





!Ipsaffenukane = NULL; 
Hndclass. IpszClasskane > (LPSTR) salpptane; 
ü (HBRUSH) GetStockObject (WHITE_BRUSH); 
WndClass.hinstance = hinstance; 
HndGlass.style = CS_HREDRAN | CS_VREDRAN; 
HndClass.1pi = UindProc; 


if(tReı aaa) &indClass)) 
rei ; 


hiind = GreateWindow((LPSTR) szAppName, 
(LPSTR| 


) A 
WS Tileurkben 6. .. 8, 


(HMRD) NULL, (HMENU) 
(HANDLE) hinstance, 
(LPSTR) NULL); 


if(tSetTiner (hknd, 1, 1888, NULL)) 
return(FALSE); 


ShowWindow(hlind, SHOW_ICONWINDOW) ; 
Updatekindow(hlind) ; 


Ve &nsg, NULL, 8, 8)) 


Translatelessage( (LPNSG) = 
Dispatchllessage( (LPNSG) Fest 


} 
Tetacnk ine} nsg.WParan); 











Listing 1: Die erste Hälfte von FreeMem enthält die Funktion 
WinMain, in der die notwendige Initialisierung erfolgt und die 
die Meldungsschleife enthält. 


Bei FreeMem können Sie allerdings tun, was Sie wollen - 
es wird immer als Sinnbild dargestellt. Die meisten 
Windows-Programme rufen kurz vor dem Eintritt in die 
Nachrichtenschleife folgende Funktion auf: 





ShowWindow(hlind, nCadShow); 
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ar FAR PASCAL met message, „Param, 1Param) 





Item Bessake: 
ie Traren! 
Steele dirk sen; Tazinen; 
char buffer[28]; 
PAINTSTROGT a5 
rect; 
BAER [BeSBHER) 
En Uni) (Globalconpact (AL) / 1024); 
men = ‚ol ’ 
if(men 1= lastaen) 
InvalidateRect(hWnd, NULL, TRUE); 
lastzen = nen; 
break; 
case WM PAINT: 
Fi 'nPaint(hHnd, (LPPAINTSTRUCT) a: 
GetClientRect(hind, (LPRECT) &rect| 
Dravfext(ps.häc, (LPSTR) buffer, 
strlen(streat(itoa(men, 
buffer, iB), „K Frei”), 
(LPRECT) &rect, DT ; 
ERRREADENNUEER, LePAINFSTRUCH aps); 
case WM DESTROY: 
Er 
ostQuitllessage(B); 
break; 
default: 
return(DefWindowProc(hhnd,message, wParam,lParam)); 
le] BL); 








Listing 2: Die zweite Hälfte von FreeMem enthält die Fen- 
‚sterprozedur mit dem Namen WndPr oc. WndProc verarbeitet 
die Meldungen, die Windows an das Fenster schickt. 


Die Variable nCmdShow wird dem Programm als Para- 
meter an WinMain übergeben. Wenn Sie ein Programm 
vom MS-DOS-Fenster aus laufen lassen, wird nCmdShow 
durch die Handle des Fensters ersetzt, das die Anwendung 
auf dem Bildschirm darstellt, wobei es sich normalerweise 
um das MS-DOS-Fenster handelt. Laden Sie aber eine An- 
wendung als Sinnbild, so wird nCmdShow gleich SHOW_ 
ICONWINDOW gesetzt. Ihr Programm muß dies normaler- 
weise nicht unterscheiden, sondern es gibt diesen Parameter 
einfach an ShowWindow weiter. 

Sie brauchen normalerweise die Variable nCmdShow 
nicht in Verbindung mit ShowWindow zu benutzen. In 
FreeMem verwende ich statt dessen die Zeile 





Showkindow(hlnd, SHOW_ICONWINDOR) ; 





Das erzwingt die Sinnbild-Darstellung des Fensters, un- 
abhängig von der Variablen nCmdShow. Sie können mit 
dieser Technik auch andere Ergebnisse erzielen. Wenn eine 
Anwendung immer in Ganzbildschirm-Darstellung starten 
soll, können Sie folgendes Statement benutzen: 
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Showkindow(hlind, SHOW_FULLSCREEN) ; 








Sie können FreeMem sogar veranlassen eine bestimmte 
Sinnbildposition am unteren Rand des Bildschirms zu 
benutzen, indem Sie den Aufruf ShowWindow in FreeMem 
durch folgenden ersetzen: 





Showindow(hhnd, (int) BxFFEF); 











Das Sinnbild wird an Position 15 positioniert, ganz am 
rechten Ende des Bildschirms. Die Syntax ist etwas son- 
derbar, aber im Programmer’s Reference Manual des Soft- 
ware Development Kits dokumentiert. 


Sinnbilddarstellung fortsetzen 


Wie ich oben schon angedeutet habe, können Sie ohne 
weiteres die Tastatur oder die Maus zum Öffnen des Free- 
Mem-Sinnbilds in ein reguläres geteiltes Fenster benutzen. 
Wenn Sie dies aber verhindern und sicherstellen wollen, 
daß FreeMem immer nur als Sinnbild dargestellt wird, so 
brauchen Sie nur die beiden Zeilen in die Funktion Wnd- 
Proc einfügen: 





case WM_QUERYOPEN: 
break; 





Ein sinnvoller Platz wäre unmittelbar vor der Stelle 





case WM_DESTROY: 











Wenn Sie jetzt die Maus benutzen, um das Sinnbild zu 
öffnen, so springt das Sinnbild einfach wieder an seinen 
Platz am unteren Bildschirmrand zurück. 

Die beiden Zeilen scheinen nicht viel zu tun, aber ein 
genauerer Blick löst das Rätsel. Microsoft Windows schickt 
die Nachricht WM_QUERYOPEN an ein Programm, wenn es 
ein Sinnbild öffnen will. Die Dokumentation besagt zu 
WM_QUERYOPEN, daß eine Windows-Funktion, wie etwa 
WndProc, 0 zurückgeben muß, um das Sinnbild vom Öffnen 
abzuhalten. Unter normalen Umständen wird die Nachricht 
WM_QUERYOPEN an die Funktion DefWindowProc weiter- 
gegeben, die einen Wert ungleich 0 liefert. (Die Funktion 
DefWindowProc ist in der Datei WINDWP.C im Windows 
Software Development Kit enthalten.) Windows öffnet dann 
das Sinnbild. 

Mit den beiden oben gezeigten Zeilen aber gibt Wnd- 
Proc den Wert 0 für die Nachricht WM_QUERYOPEN zurück. 
Somit antwortet WndProc auf die Frage von Windows, ob 
es geöffnet werden will, mit »Null«, was in diesem Falle 
»Nein Danke« bedeutet. 


NEU: MS WINDOWS 2.0 


Ein erfolgreiches Buch... 

© te-wi's Bestseller-Titel 
WINDOWS völlig über- 
arbeitet für Version 2.0 

© Zeigt die gesamte WINDOWS- 
Information in 69 leicht lesbaren 
Modulen 

© Zum Erlernen wie ein WINDOWS-2.0- 
Kurs lesbar; danach als WINDOWS-2.0- 
Lexikon 


WordPerfekt 4.2 
Einführung + Referenz 
(3. Gold) 





lexikon. Viele praktische Beispiele 
496 Seiten. Hardcover. DM 69,- 


dBase Ill+: Einführung + Referenz 
(Stult 


Üpdate des dBASE-III-Bestsellers. Kurstext und 


Lexikon in 70 Modulen. 
480 Seiten. Hardcover. DM 79, 


Star Writer PC 3.0 
fühs Handbuch 


alltägliche und seltene 
Intwortet sie in 


Form 
Hardcover. DM 49, 


Geld + Taschencomputer 


nungen 


TURBO PASCAL Systematisch 


Einführung in Sprache und Anwendung 


'n und Compilerpraxis 


DM 49, 


s der Industrie. Für sämtliche 
Über 100 Beispiele. Anspruchs 


Gliederung in 64 Module, zur Einführung als 
Kurstext lesbar, dann als alphabetisches Befehls 


...und seine Leser 


@ für WINDOWS-2.0-Beginner ein idealer 
und erprobter Selbstlerntext 

© für WINDOWS-2.0-Kenner ein ‚Lexikon 
neben dem Computer‘ 

© für WINDOWS-1.0-Benutzer bleibt der 
Vorgängertitel ‚WINDOWS‘ zu empfehlen 

© Auch als Einführung für WINDOWS/386 
geeignet. 


DESKTOP KNIGGE 
Setzerwissen für Desktop-Publisher 


skto (Philipp Luidl) 


Ein bekannter deutscher Typograph sammelte 
für alle ernsthaften Desktop-Publisher das 
traditionsreiche Berufswissen von Setzern, 
Druckern und Graphikern 

Ca. 250 Seiten. Hardcover. DM 79,- 


VENTURA PUBLISHER 1.1 
Einführung + Referenz 
(R. M. Hohol) 
Überlegt gegliederte, vollständige VENTURA 
1.01 ellung 
eiten. Hardcover. DM 79,- 


AutoCAD: 
Versionen 2.5. 2.6 und 9.0 
Einführung + Referenz 


MS DOS 
Einfache Zugänge 

(Fürst) 

Spotlights auf MS DOS für eilige PC-Benutzer. 


Noch im Programm: PC-Software: 
MS DOS, Wordstar, Multiplan, dBASE, DM 59,- 
Das 8086/8088-Buch, DM 79,— 








saeTIngc (hHnd, 1, 1886, NULL)) 
NessageBox(hnd, "Zu viele Tiner!”, NULL, MB_OK); 


Sen 'ALSE; 





Listing 3: Dieser altemative Programmteil teilt dem Benutzer 
mit, warım das Programm beendet werden muß, wenn Set- 
Timer 0 zurückgibt. 


Die Timer-Nachrichten 


FreeMem aktualisiert seine Anzeige auch wenn andere 
Programme laufen. Es führt dies mit der Hilfe des Timers 
von Microsoft Windows durch, der die Nachricht 
WM_TIMER an die Fensterfunktion sendet. In dieser Bezie- 
hung gleicht FreeMem der UHR-Anwendung,. Der Timer 
erlaubt eine Art von Multitasking, ohne daß die Anwendung 
wertvolle Prozessorzeit verschwendet. 

In der Funktion WinMain fordert FreeMem mit folgen- 
dem Statement von Windows einen Timer an: 





if(1SetTiner (hund, 1, 1888, NULL)) 
return(FALSE); 





Der dritte Parameter 1000 im Funktionsaufruf von Set- 
Timer bedeutet, daß FreeMem alle 1000 Millisekunden 
bzw. jede Sekunde eine WM_TIMER-Nachricht erhalten 
möchte. 

Wenn SetTimer 0 zurückgibt, bedeutet dies, daß kein 
Timer mehr für dieses Programm zur Verfügung steht. 
Wenn Sie je probiert haben, wie viele UHR-Programme 
gleichzeitig unter Windows laufen können, wissen Sie, daß 
das Maximum 15 ist. Jeder weitere Aufruf von SetTimer 
gibt 0 zurück. Tatsächlich gibt es einen Weg, von Windows 
mehr als 15 Timer zu erhalten, der ist aber etwas kompli- 
zierter, 

Wenn FreeMem keinen Timer erhält, muß die Funktion 
WinMain den Wert 0 (Wert für FALSE) zurückgeben, was 
zum Programmabbruch führt. Wie Sie an den beiden ande- 
ren Zeilen mit return (FALSE) in WinMain sehen, wird 
FreeMem auch beendet, wenn es schon einmal läuft oder 
wenn es die Fensterklasse nicht registrieren kann. Obwohl 
es nicht unbedingt notwendig wäre, mehrere Vorkommen 
von FreeMem nicht zuzulassen, macht es doch nicht viel 
Sinn. 

Wenn Sie möchten, daß FreeMem Ihnen mitteilt, 
warum es abbricht, wenn kein Timer mehr vorhanden ist, so 
können Sie den Programmteil aus Listing 3 verwenden. 
Dieser Teil ist informativer, aber nicht besonders höflich. 

Der zweite Parameter beim Aufruf SetTimer wird als 
Timer-ID bezeichnet. Beim Erhalt der Nachricht 
WM_TIMER bekommt die Funktion WndProc im Parameter 
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wParam diesen Wert. Durch die Verwendung mehrerer 
Timer-IDs kann eine Windows-Anwendung mehrere Timer 
für unterschiedliche Aufgaben einsetzen. FreeMem muß die 
Timer-ID auch zum Zurückgeben des Timers mittels 
KillTimer verwenden, wenn WndProc die Nachricht 
WM_DESTROY erhält. 

Die Nachrichten WM_TIMER sind nicht asynchron. Die 
Angabe von 1000 Millisekunden im Aufruf SetTimer, 
garantiert nicht, daß die Fensterfunktion genau jede 
Sekunde die Nachricht WM_TIMER erhält. Die WM_TIMER- 
Nachrichten werden in der normalen Nachrichtenschlange 
verwaltet und mit den anderen Nachrichten synchronisiert. 

Ist eine andere Anwendung länger als eine Sekunde 
aktiv, so erhält FreeMem während dieser Zeit keine einzige 
WM_TIMER-Nachricht. FreeMem erhält seine nächste 
WM_TIMER-Nachricht erst aus der Schlange, wenn die 
andere Anwendung die Kontrolle durch einen Aufruf von 
GetMessage, PeekMessage oder WaitMessage abgibt. 

Tatsächlich werden WM_TIMER-Nachrichten ebenso wie 
WM_PAINT-Nachrichten von Microsoft Windows mit niedri- 
ger Priorität gehandhabt. Das bedeutet, daß die Kontrolle 
an andere Programme nur abgegeben wird, wenn die Nach- 
richtenschlange des Programms leer ist. In Wirklichkeit 
aber wird die Kontrolle an ein anderes Programm über- 
geben, wenn das aktuelle nur WA_PAINT- oder WM_TIMER- 
Nachrichten in seiner Schlange enthält, das andere aber 
irgendeine andere Nachricht, außer diesen beiden. 

Des weiteren fügt Windows keine zusätzlichen 
WM_TIMER-Nachrichten in die Schlange ein, wenn eine 
andere Anwendung läuft. In diesem Fall faßt Windows 
mehrere WM_TIMER-Nachrichten zu einer zusammen, so 
daß die Anwendung nicht mehrere davon auf einmal erhält. 

Obwohl die Handhabung der WM_TIMER-Nachrichten 
für ein Programm wie FreeMem genügt, sollten Sie diesen 
Aspekt im Auge behalten, falls Sie je ein Programm wie die 
Windows-UHR entwickeln. Ein Timer-Wert von 1000 Milli- 
sekunden garantiert keine 3600 WM_TIMER-Nachrichten je 
Stunde. Wenn Sie eine WM_TIMER-Nachricht erhalten, 
sollten Sie die wirkliche Zeit entweder durch eine C-Funk- 
tion, oder durch MS-DOS selbst in Erfahrung bringen. Sie 
können die Zeit nicht allein aufgrund von WM_TIMER-Nach- 
richten mitführen. 


Berechnung des Speichers 


Beim Erhalt der Nachricht WM_TIMER muß FreeMem die 
Größe des freien Speichers bestimmen. Diese kleine Auf- 
gabe stellte die größte Anforderung beim Programmieren 
von FreeMem. Ich wußte, daß die Information verfügbar ist, 
da das MS-DOS-Fenster in der About-Box den Wert des 
freien Speichers anzeigt. Da aber Microsoft Windows unge- 
fähr 400 Funktionen zur Verfügung stellt, ist es ab und zu 
etwas schwierig, die benötigte Funktion zu finden. 

Es stellte sich heraus, daß das MS-DOS-Fenster die 
Information des freien Speichers durch den Aufruf von 





GlobalCompact mit einem Parameter von 0 erhält. Win- 
dows-Programme rufen die Funktion GlobalCompact 
normalerweise auf, um freien Speicher vom globalen Heap 
zu erhalten. Wenn es notwendig ist, komprimiert Windows 
die Speicherblöcke und gibt die als discardable mar- 
kierten Segmente beim Aufruf von GlobalCompact frei. 
(Der globale Heap setzt sich aus Speicher außerhalb des 
lokalen Datensegments zusammen.) 

Genaueres Nachlesen der Dokumentation zu Global- 
Compact ergab, daß im Falle des Parameters 0 die Funk- 
tion einen Wert zurückgibt, den Speicher aber nicht ver- 
schiebt. So ist der von FreeMem angezeigte Wert wirklich 
der mögliche freie Speicher, und nicht der aktuelle freie 
Speicher. Der Wert gibt an, wieviel Speicher eine Windows- 
Anwendung vom globalen Heap im Bedarfsfalle erhalten 
könnte. 

Wenn Sie mit dem Hilfsprogramm HEAPWALK, das 
im Software Development Kit enthalten ist, vertraut sind, 
können Sie eine Menge Zeit damit verbringen, die Werte 
von FreeMem und HEAPWALK in Übereinstimmung zu 
bringen. Es scheint einfach nicht einsichtig zu sein. Glo- 
balCompact gibt ungefähr die Größe des Bereichs des 
freien Speichers in der Mitte des von Windows verwalteten 
Speicherpools zurück und zusätzlich einige discardable- 
Segmente über diesem Bereich des freien Speichers. Kurz 
vor dem discardable Codesegment von FreeMem bricht 
es aber ab. GlLobalCompact kann den Code von FreeMem 
selbstverständlich nicht auslagern, wenn FreeMem selbst 
diese Funktion aufruft. 


Zeichnen des Sinnbilds 


In FreeMem wickelt der Programmteil, der die WM_TIMER- 
Nachrichten bearbeitet, nicht selbst die Aktualisierung des 
angezeigten Sinnbilds ab. Statt dessen zeigt folgender Funk- 
tionsaufruf 





InvalidateRect(hHnd, NULL, TRUE); 











Windows an, daß der Inhalt des Fensters von FreeMem 
jetzt ungültig ist und deshalb aktualisiert werden muß. Die 
Funktion InvalidateRect veranlaßt Windows eine 
WM_PAINT-Nachricht in die Nachrichtenschlange einzu- 
fügen. WndProc aktualisiert das Fenster nur beim Erhalt 
dieser WM_PAINT-Nachricht. 

Es gibt Alternativen zu dieser Methode. Statt des Auf- 
rufs InvalidateRect kann WM_PAINT das Fenster direkt 
aktualisieren. Es ist notwendig, den Anzeige-Kontext zu 
erhalten mit dem Aufruf: 





hDC = GetDC(hind); 

















NAME Freellen 
DESCRIPTION "Free Memory Display by Charles Petzold’ 
STUB "WINSTUB.EXE* 
CODE MOVEABLE 
DATA MOVEABLE MULTIPLE 
HEAPSIZE 1824 
STACKSIZE 4896 
KndProc @1 








Listing 4: Die Moduldefinitionsdatei FREEMEM.DEF wird für 
Informationen benötigt, die nicht im Quellcode definiert sind. 


Anschließend sind Aufrufe von GetClientRect und 
DrawText erforderlich, ähnlich wie in der WM_PAINT- 
Logik, aber unter der Verwendung von hDC als Anzeige- 
Kontext, statt ps.hdc. WM_PAINT müßte anschließend 
den Anzeige-Kontext wieder freigeben: 





ReleaseDC(hkind, hDC); 








Obwohl das sicher korrekt ist, wählte ich einen anderen 
Weg. WndProc muß auch die WA_PAINT-Nachrichten bear- 
beiten, die aus anderen Gründen, als dem Aktualisieren des 
Wertes für den freien Speicher, gesendet werden. Wenn Sie 
zum Beispiel die Maus zum Verschieben des FreeMem- 
Sinnbilds verwenden, sendet Windows unter Umständen 
eine WM_PAINT-Nachricht, damit FreeMem sein Sinnbild 
erneut darstellen kann. Deshalb muß entweder der Anzei- 
gecode dupliziert oder in eine Funktion verlagert werden. 

Der Aufruf von InvalidateRect erledigt dies 
tatsächlich für uns, indem er die Nachricht WM_PAINT 
erzeugt. Dies erlaubt es, denselben Anzeigecode für alle 
Anzeigearbeiten zu verwenden. 

Die WM_PAINT-Nachrichten besitzen in Windows eine 
niedrige Priorität. Sie werden immer an das Ende der 
Nachrichtenschlange angehängt, und werden aus der 
Schlange nur geholt, wenn keine andere Nachricht mehr 
vorhanden ist. Es gibt aber auch einen Ausweg. Nach dem 
Aufruf von InvalidateRect kann WM_TIMER dann 





Updatehindow(hhnd); 











aufrufen, genau wie wir es in WinMain durchführten. 
Dies veranlaßt Windows, die WndProc-Funktion direkt mit 
der Nachricht WM_PAINT aufzurufen, ohne Umweg über 
die Nachrichtenschlange. Dies ist aber hier wirklich nicht 
notwendig. Ich möchte FreeMem als Task mit niedriger 
Priorität arbeiten lassen. Wenn in einer anderen Anwen- 
dung etwas los ist, möchte ich nicht, daß FreeMem durch 
ständiges Neuzeichnen des Sinnbilds Zeit verschwendet. 
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Windows 





Aake-Datei für FREEMEN 


freemen.obj: _freenen.c 
el -e -d -Gsw -Os -K2 -Zdp freemen.c 


freenen.exe: ar! freemen.def 
link4 freemen, /align:16, /nap/line, slibv, freenen 
napsyn freenen 








Listing 5: Diese Datei mit dem Namen FREEMEM (ohne 
Erweiterung) ist die Make-Datei für die Generierung von 
FREEMEM.EXE. 


Die von FreeMem beim Bearbeiten der Nachricht 
WM_PAINT benützte Funktion DrawText ist sehr ange- 
nehm für einfachen Wortumbruchstext. Bedenken Sie, daß 
die Zeile mit dem Aufruf DrawText 


strlen(streat(itoa(mem, buffer, 18), "K Frei")) 


denselben Zweck erfüllt, wie der gewohntere Ausdruck 














sprintf(buffer, "*dK Frei”, men) 








Sprintf ist jedoch eine große Funktion. Durch die 
Verwendung von strlen, strcat und itoa können wir 
die Größe von FREEMEM.EXE um ungefähr 3 Kbyte redu- 
zieren. Nicht viel, aber doch etwas. 


Die Erzeugung von FreeMem 


Neben dem Quellcode von FREEMEM.C benötigen Sie noch 
zwei andere Dateien für die Erzeugung von FreeMem. Die 
erste Datei ist die Moduldefinitionsdatei FREEMEM.DEF 
(Listing 4). Die Datei FREEMEM.DEF enthält die Standard- 
Informationen, wie sie für die meisten kleinen Windows- 
‚Anwendungen typisch sind. 

Das Programm WINSTUB.EXE, das in der Zeile STUB in 
FREEMEM. DEF angegeben ist, ist im Software Development 
Kit enthalten. Dieses Programm läuft, wenn Sie FreeMem 
außerhalb von Windows aufrufen. Es zeigt einfach die Mel- 
dung »This Programm requires Microsoft Windows« an. 

Wenn Sie wollen, können Sie ein normales MS-DOS- 
Programm erzeugen, das den freien Speicher ähnlich dem 
von CHKDSK errechneten Wert anzeigt. Wenn Sie sich ent- 
scheiden, dieses normale MS-DOS-Programm zum Beispiel 
DOSFREE.EXE zu benennen, können Sie in der Datei 
FREEMEM. DEF angeben. 





STUB *DOSFREE..EXE" 
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Dieser kleine Trick gestattet die Verwendung von Free- 
Mem sowohl auf der MS-DOS-Kommandoebene, als auch 
unter Windows. FREEMEM.EXE enthält dann zwei verwand- 
te, aber ziemlich unähnliche Programme in einer Datei. Die 
MAKE-Datei von FreeMem (die einfach FREEMEM ohne 
Erweiterung heißt) ist im Listing 5 zu schen. Wenn Sie den 
Befehl 





MAKE FREEMEM 








ausführen, wird der Quellcode von FREEMEM.C über- 
setzt und mit den zugehörigen Windows und C-Bibliothe- 
ken und den Informationen aus der Definitionsdatei FREE- 
MEM. DEF gelinkt. 


Keine Ressourcendatei? 


Im Gegensatz zu vielen einfachen Windows-Anwendungen 
benötigt FreeMem keine Ressourcendatei (eine Datei mit 
dem Zusatz .RC). FreeMem verfügt über kein Menü, kein 
bildhaftes Sinnbild und keine Dialogboxen. Die einzige 
Anwendung, die wir für eine Ressourcendatei hätten, wäre 
die zum Speichern von Zeichenketten. Die einzige Zeichen- 
kette, die FreeMem benötigt, ist aber der Text mit dem 
Wort Free. 

Für längere Programme ist die Verwendung einer Res- 
sourcendatei dringend angeraten, um alle Textstrings zu 
speichern, da hierdurch eine Übersetzung des Programms 
in eine andere Sprache vereinfacht wird. Für ein kleines 
Programm stellt das Laden von Zeichenketten aus der Res- 
sourcendatei aber eine Last dar. FreeMem ist klein genug, 
daß das Übersetzen kein großes Problem darstellt, und man 
wäre päpstlicher als der Papst, würde man für diesen 
einzigen Textstring eine Ressourcendatei verwenden. 


Nutzen in der Entwicklung 


Ich mag FreeMem gern unter Windows geladen und laufen 
haben, nur um mich aufmerksam zu machen, wann Win- 
dows der Speicher zu eng wird. Aber der Nutzen bei der 
Programmentwicklung ist selbstverständlich größer. 

Wenn Sie eine Windows-Anwendung entwickeln, richten 
Sie während des Testens einen Blick auf das FreeMem- 
Sinnbild. Sollte die Größe des freien Speichers kleiner 
werden, haben Sie vermutlich vergessen, allokierten 
Speicher im Programm wieder freizugeben. Sie müßten 
dann die Utility HEAPWALKER zu Rate ziehen, um diese 
verlorenen Speicherblöcke ausfindig zu machen. 

Bedenken Sie aber, daß FreeMem vor und nach dem 
Programmlauf einer Anwendung nicht den gleichen Wert 
anzeigt. Die Komplexität der Speicherverwaltung von Win- 
dows ist für diesen Unterschied bei den meisten großen 
Programmen verantwortlich. 

Charles Petzold 
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TIFF: Der neue Grafikstandard 


In den Anfangstagen der Microcomputer waren 
die Anwender schon froh, wenn sie ein Zeichen- 
programm besaßen, das elementare Zeichenope- 
rationen unterstützte. Sie konnten einfache 
Zeichnungen für Dokumente anfertigen, diese 
ausdrucken und sie per Hand einfügen. Leider 
sah das Ergebnis amateurhaft aus und war oft- 
mals fast nicht akzeptabel. 


Die Schwierigkeit bestand darin, daß keine mächtigeren 
Werkzeuge vorhanden waren, die die Zeichenwünsche be- 
friedigten. Was war, wenn die Anwender vorhandene Foto- 
grafien benutzen wollten? Sie brauchten eine Möglichkeit, 
die professionellen Zeichnungen zu digitalisieren und sie 
dann elektronisch in die Dokumente einzufügen. 

Das änderte sich mit der Entwicklung der Scanner. Die 
meisten verfügbaren Scanner können vorhandene Kunst- 
werke oder Fotografien mit einer Auflösung von 300 Punk- 
ten/Zoll (dpi) abtasten. Das klingt nach der Erfüllung von 
Träumen, aber es fehlt noch ein Mosaiksteinchen. Die 
Anwender benötigen noch ein Standard-Dateiformat, um 
jeden beliebigen Scanner zum Digitalisieren von Abbildun- 
gen verwenden zu können, diese dann mit jedem Zeichen- 
oder Grafik-Programm ihrer Wahl bearbeiten zu können, 
und dann das Abbild elektronisch in das Dokument ein- 
fügen zu können. Wenn zu guter Letzt der ganze Vorgang 
noch in kurzer Zeit zu bewältigen wäre, würde die Erfüllung 
des Traums wahr. 


Was ist TIFF? 


Die Aldus Corporation, der Entwickler von PageMaker für 
den Macintosh und den PC, erkannte die Notwendigkeit 
einer standardisierten Methode, digitale Daten auszutau- 
schen, und entwickelte zusammen mit mehreren Herstellern 
das Tagged Image File Format (TIFF). TIFF unterstützt 
viele Eingabeeinheiten und Datenkomprimierungstechniken 
und bietet die Möglichkeit, Neuerungen in einer einfachen, 
kontrollierten Art hinzuzufügen. 

TIFF unterstützt Scanner, Zeichenprogramme und 
Kameras (Bild 1). Es arbeitet genausogut mit einer ein- 
fachen Windows Paint-Zeichnung, wie mit einem kompli- 
zierten medizinischen Scanner. TIFF-Dateien enthalten 
Kennungen (tags), die nicht nur die Höhe und Breite des 
Bildes beschreiben, sondern enthalten auch Auflösungs- 
informationen, Informationen über die Graustufen oder 
Farben und das Komprimierungsverfahren, mit dem sie 
erstellt wurden. 

Augenblicklich unterstützt TIFF eine modifizierte Ver- 
sion der RL-Komprimierung CCITT Gruppe 3. CCITT/3 
bietet eine vernünftige Komprimierung für Schwarz/Weiß- 
Bilder mit 200 bis 300 dpi, indem es kontinuierliche 
schwarze oder weiße Bildpunkte erkennt. Diese werden 
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Bild 1: TIFF kann aufgrund seiner Fähigkeiten mit Scannern, 
Zeichenprogrammen und Kameras verwendet werden. Grafi- 
ken einfacher Zeichenprogramme werden genauso gehand- 
‚habt, wie komplexe medizinische Dokumente. 


durch ein eindeutiges Codewort ersetzt, womit die Origi- 
naldaten wiedergewonnen werden können. Die Komprimie- 
rung kommt zustande, da die Codeworte typischerweise 
kürzer sind als die Daten, die ersetzt werden. Die 
CCITT/3-Komprimierung für Grauwerte oder Farbdarstel- 
lungen ist nicht so gut, da hier nicht so viele redundante 
Informationen enthalten sind, wie in Schwarz/Weiß-Bil- 
dern. Aus diesem Grund unterstützt TIFF auch ein ein- 
faches gepacktes Format, bei dem Daten so dicht wie mög- 
lich in Bytes untergebracht werden, wobei keine Bits über- 
flüssig sind, außer am Ende einer Reihe. Spezielle Kompri- 
mierungsverfahren für Grau und Farbbilder werden noch 
kommen. Microsoft, der derzeitige Koordinator der TIFF- 
Spezifikation, wird Ihre Ratschläge begrüßen. 
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Bild 2: Aufbau eines festen Dateiformats. 


TIFF ermöglicht es, Neuerungen hinzuzufügen, ohne 
daß bestehende Software jedesmal umgeschrieben werden 
muß. Will zum Beispiel eine Applikation eine Kennung 
»Datum der Entstehung« zum Bild hinzufügen, kann das 
beim Programmieren der Applikation geschehen. Andere 
Applikationen, die die TIFF-Dateien lesen, brauchen nicht 
geändert zu werden, außer wenn sie diese neue Datums- 
kennung auswerten wollen. Sie können in den meisten 
Fällen ohne Probleme die unbekannten Kennungen ignorie- 
ren, Die TIFF-Spezifikation versichert, daß der Strukturie- 
rung der Daten schr viel Aufmerksamkeit gewidmet wurde, 
um zukünftige Erweiterungen leicht implementieren zu 
können. Sollten in Zukunft Farbscanner verfügbar sein, so 
wird TIFF auch diese unterstützen können. 


Die Arbeitsweise von TIFF 


Herkömmliche Zeichenprogramme wie PC Paintbrush 
benützen eine feste Dateiorganisation (Bild 2). Die Organi- 
sation und der Platz jedes Wertes ist vor dem Lesen 
bekannt. Die Auflösung in der X-Achse zum Beispiel steht 
immer in den Bytes 2 und 3 des Satzes. 

TIFF ist nicht positionsabhängig, stattdessen benutzt es 
Informationen mit Kennungen, eine Methode die vornehm- 
lich bei Datenbanken zu finden ist. Kennungen definieren 
die Attribute des Bildes und wie das wirkliche Bild gespei- 
chert ist. Jedes Bild besitzt einen Header, an den sich Ken- 
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Bild 3: TIFF verwendet Informationen mit Kennungen, eine 
Methode die vomehmlich bei Datenbanken zu finden ist. Ken- 
nungen definieren die Attribute des Bildes und wie das wirk- 
liche Bild gespeichert ist. Jedes Bild besitzt einen Header, an 
den sich Kennungen anschließen, die Informationen beschrei- 
ben, die irgendwo anders in der Datei enthalten sind. 


nungen anschließen, die Informationen beschreiben, die 
irgendwo in der Datei enthalten sind. Kennungen beinhal- 
ten den Namen der Kennungs-Information, die Größe und 
Länge der in der Kennung beschriebenen Information, und 
einen Zeiger auf die wirkliche Information (Bild 3). Ken- 
nungen können um alle zum Speichern des Bildes benötig- 
ten Informationen erweitert werden. Sie können deshalb so 
viele Kennungen anfügen, wie Sie benötigen. Für einfache 
Bilder brauchen Sie nur einige Kennungen, für komplexe 
hingegen können es sehr viele sein. 
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Bild 4: Der Header und die Kennungen einer Bilddatei 
werden Image File Directory (IFD) genannt. 


Der Header und die Kennungen einer Bilddatei werden 
Image File Directory (IFD) genannt. Die Struktur erlaubt 
es auch, mehrere Versionen des Bildes in derselben Datei 
zu speichern. Dies kann sehr hilfreich sein, wenn Sie eine 
Version mit voller Auflösung zum Bearbeiten und Drucken 
und eine Version mit niedrigerer Auflösung für eine höhere 
Bildschirm-Anzeigegeschwindigkeit in einer Datei speichern 
wollen, wie dies in Bild 4 gezeigt ist. Jede Version hat ihre 
eigene IFD mit eindeutigen Attributen und Zeigern zu den 
aktuellen Daten. TIFF erlaubt Ihnen das Speichern in 
Streifen mit variabler Länge oder in Bildpunktzeilen, um 
Ihnen wahlfreien Zugriff zu jedem Teil des Bildes zu 
ermöglichen. Brauchen Sie nur einen Teil eines sehr großen 
Bildes und haben dieses in Streifen abgespeichert, können 
Sie nur diejenigen Streifen expandieren und laden, die Sie 
benötigen. Beim Verändern eines Bildes ist es ebenfalls nur 
notwendig, die veränderten Streifen des Bildes zu aktuali- 
sieren, nicht das ganze Bild. 


Die Struktur erlaubt es auch, mehrere Versionen eines Bildes 
in derselben Datei zu speichern. 


Vorteile 


Für Software- und Hardware-Entwickler sind die Vorteile 
eines Standardformats für den Austausch digitaler Daten 
groß. Statt der Unterstützung zahlreicher Formate für jeden 
Scannerhersteller, jeder Dektop-Publishing-Applikation und 
jedes Zeichenprogramms, brauchen die Hersteller nur ein 
Dateiformat zu betreuen. Sogar die Unterstützung eines 
komplizierten Formats, wie TIFF es verwendet, ist leichter, 
als die ständig zunehmende Anzahl verschiedener Formate, 

TIFF ist ein »großzügiges« Dateiformat. Statt der Rück- 
führung aller Bilder auf den kleinsten gemeinsamen Nen- 
ner, ist TIFF für die Bearbeitung verschiedener Arten von 
Bildern, wie Strichvorlagen, Graustufen, Farben und auch 
verschiedene Auflösungen, ausgelegt. TIFF unterstützt ver- 
schiedene Komprimierungsverfahren und ist sogar so flexi- 
bel, daß der Komprimierungs-Algorithmus an den Datentyp 
angepaßt werden kann. TIFF wird erweitert werden, um 
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Das CCITT/3-Schema in TIFF 


Das im TIFF-Format benutzte CCITT/3-Schema erkennt 
kontinuierliche Verläufe, genannt Längenverläufe, von 
weißen bzw. schwarzen Pixeln. Jeder dieser Längenverläufe 
wird durch ein Codewort ersetzt, mit dem später der konti- 
nuierliche Verlauf der Daten wiederhergestellt werden 
kann. 

Das Komprimierungsschema besteht aus zwei Tabellen. 
Die eine Tabelle enthält Codewörter für verschiedene Ver- 
läufe weißer Pixel von der Länge von 0 bis 63 Pixeln. Die 
andere Tabelle enthält Codewörter für die gleichen konti- 
nuierlichen Verläufe schwarzer Pixel. Die Tabellen enthal- 
ten auch Werte für vereinzelte Längenverläufe oberhalb von 
63. Wenn die Längenverläufe weißer oder schwarzer Pixel 
63 überschreiten, werden Kombinationen der Codewörter 
oberhalb und unterhalb von 63 benutzt, um diese größeren 
Längenverläufe zu komprimieren. 

Jede Reihe Bitmaps wird unabhängig voneinander kom- 
primiert. Außerdem muß jede Reihe mit einem weißen 
Muster beginnen und auf einer Bytegrenze enden. Der 
Beginn mit einem weißen Muster liefert die Synchronisation 
und sagt dem Dekomprimierungs-Algorithmus, ob er in der 


kompliziertere Bilder und Komprimierungstechniken zu 
unterstützen, sofern die Technologie voranschreitet. Das 
Hinzufügen weiterer Neuerungen erfordert kein Änderung 
bestehender Applikationen, sofern diese von den erweiter- 
ten Fähigkeiten keinen Gebrauch machen wollen. Neben 
der Behandlung komplizierter Bilder arbeitet TIFF auch 
mit einfachen Bildern, zum Beispiel von Zeichenprogram- 
men, da die Applikation auch nur diejenigen Teile von TIFF 
verwenden kann, die sie benötigt. 

Ein weiterer Vorteil von TIFF ist die Maschinenunab- 
hängigkeit. Sie können es mit den Mikroprozessoren von 
Intel oder Motorola, den Betriebssystemen UNIX, MS- 
DOS oder dem des Macintosh verwenden, was Mitch 
Murphy, den Projektmanager von OptiGraphics veranlaßte, 
auf TIFF umzustellen. OptiGraphics, die Workstations für 
Ingenieure und Scanner für große Dokumente herstellen, 
suchten ein Dateiformat für PCs und UNIX-Computer. 
Murphy wählte TIFF, um seine Applikationen verbessern 
zu können und kompatibel zu bleiben. Produkte der 
Gruppe von Murphy, wie View! und Markup!, sind 
Microsoft Windows-Applikationen, mit denen Sie große 
Ingenieur- und Architekten-Zeichnungen betrachten, und 
kleinere Änderungen vornehmen können. Der Scanner gibt 
die Bilder in TIFF aus, und View! bzw. Markup! lesen die 
TIFF-Ausgabe und zeigen sie an. Benötigt eine Zeichnung 
intensivere Bearbeitung, gibt es Produkte, die eine Tiff- 
Datei automatisch mit Vektoren versehen, um sie auf einem 
CAD-System verwenden zu können. 


22 Microsoft System Journal Juli/August 1988 


Tabelle für die weißen oder schwarzen Längenverläufe 
suchen soll. Wenn die Reihe mit einem oder mehreren 
schwarzen Pixeln beginnt, dann muß am Anfang im Code- 
wort der komprimierten Daten ein weißes Pixel der Länge 0 
eingetragen sein. 

Die für Fax-Anwendungen nach CCITT/3 gebräuch- 
lichen Zeilenende-Markierungen (EOL) werden nicht 
benutzt. Werden sie dennoch eingefügt, können die Infor- 
mationen von der Lese-Einheit der TIFF-Datei nicht inter- 
pretiert werden. Ebenso paßt bei Anwendung der CCITT- 
Komprimierung die TIFF-Kennung nicht zur Interpretation 
der Photometrie. Die Werte für Weiß und Schwarz sind 
vordefiniert. Sie müssen eventuell alle Binärdaten invertie- 
ren, bevor sie in CCITT-Format kodiert werden. 

Füllbits einer unkomprimierten Bildzeile dürfen nicht 
komprimiert werden. Sie sollten nur die Datenlänge kom- 
primieren, die im Breitenfeld der Kennung definiert ist. 
Wenn z.B. eine Bitmap aus 10 Pixeln besteht, wird sie 
unkomprimiert in 2 Bytes gespeichert, so daß jede Reihe 
mit einer Bytegrenze beginnt. In diesem Fall würden 6 Füll- 
bits hinzugefügt. Beim Komprimieren dieser Information 
sollten nur die ersten zehn Bits zur Komprimierung heran- 
gezogen werden, jedoch nicht die sechs Füllbits. 





Einschränkungen 


Die Großzügigkeit von TIFF, die eine seiner Vorteile ist, ist 
ebenso die Quelle für einige Beschränkungen. Obwohl es 
für einen Scanner nicht schwer ist, eine TIFF-Bilddatei zu 
schreiben, ist es schwierig einen TIFF-Leser zu schreiben. 
Der Präsident von MacroMinds, Marc Cantor, betrachtet es 
als Fehler von Aldus und Microsoft, daß die TIFF-Spezifi- 
kation keinen Dekodieralgorithmus enthält. Derzeit muß 
jede Gesellschaft ihren eigenen Parser programmieren. 
Cantors Firma, deren Programm Graphie Works ein ge- 
scanntes TIFF-Dokument jeder Größe liest, hat ihren eige- 
nen Parser geschrieben und bietet diesen auch zum Verkauf 
an. Um das Problem zukünftig zu beheben, wird Microsoft 
TIFF-Werkzeuge anbieten. 

Eine weitere Einschränkung ist, daß es keine Standard- 
TIFF-Datei gibt, das heißt, keine gemeinsame Untermenge 
von Eigenschaften, die jeder, der den Namen TIFF verwen- 
det, unterstützen muß. Verschiedene Hersteller können 
verschiedene Kennungen von TIFF unterstützen. Murphy 
von OptiGraphics meint, daß TIFF so mächtig ist, daß mch- 
rere Dialekte entstehen werden. Um dies zu vermeiden, 
schlagen er und andere vor, gemeinsame Werkzeuge zu 
verwenden, die zwischenzeitlich vermehrt angeboten wer- 
den. Murphy hat eine Bibliothek von Funktionen, um auf 
TIFF-Dateien in einer geordneten Weise zuzugreifen. Sie 
können bei ihm kostenlos bezogen werden (Telefon 001- 


612-292-6060), und von Ihnen auf Ihre eigene Verantwor- 
tung eingesetzt werden. Die Entwicklungsingenieure bei 
Hewlett-Packard haben einen entscheidenden Beitrag zur 
TIFF-Spezifikation geleistet, und ein »Guide to Tagged 
Image File Format« verfaßt. Diese Spezifikation ist auch 
Bestandteil des Windows Software Development Kit 2.0. 
Hewlett-Packard verfügt ebenso über Quellcode für das 
Schreiben, Lesen, Komprimieren, Expandieren und Debug- 
gen von TIFF-Dateien. Zur Information können Sie sich an 
HPs ISV Marketing Department unter der Telefonnummer 
.001-303-350-4000 wenden. Dest Corporation, der Hersteller 
von Scannerhardware verfügt ebenso über eine Bibliothek 
von Funktionen, die er Herstellern von Desktop Publishing 
Systemen kostenlos zur Verfügung stellen will. Die Tele- 
fonnummer ist 001-408-946-7100. Tim Davenport von Aldus 
wird Ihnen einfache TIFF Dateien schicken, wenn Sie ihn 
unter der Nummer 001-206-622-5500 anrufen. 


Der neue Standard? 


TIFF wird sicherlich der Standard für den Umgang mit 
pixelorientierten Bildern. Firmen wie HP, Aldus und Opti- 
Graphics haben eine Menge Entwicklungsarbeit in TIFF 
gesteckt. Murphy meint, da sie von TIFF überzeugt sind, 
wollen sie andere auch überzeugen und bieten auch Unter- 
stützung. David Rosenbloom von Cygnet Technologies, eine 
High End Telekommunikationsfirma, wählte für sein FAX- 
Produkt TIFF statt eines gewöhnlichen Formats, da es alles 
bietet, was sie brauchen: einen universellen Header mit 
einer unbeschränkten Anzahl von Feldern, und die Aus- 
sicht, der akzeptierte Standard zu werden. Andere Firmen, 
die angekündigt haben, daß sie TIFF unterstützen werden, 
sind Dest, DataCopy, Microsoft, Microtek, Media Cyberne- 
tics, New Image Technology und Software Publishing. Die 
Unterstützung von TIFF überbrückt die traditionellen 
Schluchten zwischen den PC- und den Macintosh-Lagern. 


Obwohl Steve Carlson von Aldus der Initiator der TIFF- 
Spezifikation ist, ist jetzt Microsoft zuständig. Mit Microsoft 
anstelle eines Herstellers von Hardware oder Desktop 
Publishing Systemen, steht TIFF unter neutraler Koordina- 
tion. Die Firmen sehen TIFF mehr als Standard, als eine 
Hilfe für Konkurrenten. Microsoft arbeitet derzeit mit 
denjenigen Firmen, deren Produkte Bilder scannen und 
archivieren. Man will aber auch mit den Herstellern von 
Seitenbeschreibungen, wie Adobe, DDL und Interpress 
zusammenarbeiten, um sicherzustellen, daß die von TIFF 
unterstützten Funktionen von zukünftigen Seitenbeschrei- 
bungssprachen auch unterstützt werden. Wenn es zum Bei- 
spiel kompatible Komprimierungsverfahren gibt, wird sich 
die Druckzeit erheblich verkürzen. Manny Vellon von der 
Microsoft Windows Marketing Group ist der neue TIFF- 
Administrator. Sie können bei ihm eine Kopie der TIFF- 
Spezifikation anfordern und ihm auch Ihre Vorschläge 
übersenden. 


Derzeit ist der Desktop Publishing Markt am meisten an 
TIFF interessiert, aber er expandiert in Richtung OCR, 
FAX, dreidimensionaler CAD und Medizintechnik. Eines 
Tages werden Sie statt in die Bücherei zu gehen, um einen 
Kunstdruckband zu holen, von einer CD-ROM qualitativ 
hochwertige Bilder im TIFF-Format bekommen. Bald wer- 
den Sie eine technische Zeichnung als FAX auf Ihrem PC 
empfangen, ein Programm zur Vektorisierung dieser 
Zeichnung verwenden, sie mit Ihrem CAD-Programm bear- 
beiten, die Spezifikationen, die diese Zeichnung in einem 
anderen FAX begleitet, in OCR umwandeln, diese mit 
Ihrem Textverarbeitungssystem bearbeiten und alles in 
FAX-Form zurücksenden können. Diese Hardware- und 
Software-Applikationen werden zusammenarbeiten, sobald 
es einen Standard für den Austausch von digitalen Daten 
gibt. TIFF ist auf dem besten Weg dazu. 

Nancy Andrews/Stan Fry 


Gibt es preiswerter Informationen, 
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Jüngste Version des MS-OS/2-SDK wird mit 
Vorversion des Presentation Managers 
ausgeliefert 


Das Software-Entwicklungs-Kit (SDK) für das neue 
Betriebssystem MS-OS/2 enthält einen kompletten Satz 
Dokumentationen zu MS-OS/2, eine vorläufige Version des 
Betriebssystems MS-OS/2 1.1 und die Entwicklungswerk- 
zeuge, die notwendig sind, um Applikationssoftware für 
MS-OS/2 einschließlich Presentation Manager zu ent- 
wickeln und zu testen. Diese Ausgabe des MS-OS/2-SDK 
ist die dritte Aktualisierung, seit Microsoft das Software- 
Entwicklungs-Kit im Juni 1987 zum ersten Mal ausgeliefert 
hat. Microsoft plant darüber hinaus vor Erscheinen der 
endgültigen Version von MS-OS/2, Version 1.1, weitere 
Aktualisierungen des SDK. 

»Dieses MS-OS/2-Entwicklungs-Kit ist ein Meilenstein 
für Microsoft«, so Christian Wedell, Geschäftsführer der 
deutschen Microsoft GmbH. »Die Verfügbarkeit des MS- 
08/2-SDK für das OS/2-Betriebssystem mit Presentation 
Manager zeigt, daß wir unser Ziel erreicht haben, den Ent- 
wicklern in einem frühen Stadium die Basis zur Entwick- 
lung von Applikationssoftware für MS-OS/2, Version 1.1, 
zur Verfügung zu stellen. Obwohl diese Vorversion natur- 
gemäß noch einige Fehler enthält, sind wir überzeugt, daß 
die Entwickler von MS-OS/2-Applikationssoftware damit 
gute Fortschritte in der Entwicklung neuartiger und beson- 
ders leistungsfähiger Applikationssoftware machen. Mit die- 
ser neuen SDK-Version beginnt der Countdown für die 
Entwicklung von MS-OS/2-Presentation Manager-Applika- 
tionen, Die meisten Softwarehäuser haben dieses grafische 
Interface als Entwicklungsumgebung gewählt. Deshalb ist 
das neue SDK ein Meilenstein für die Durchsetzung des 
neuen Standards.« 

Das SDK enthält Dokumentationen mit mehr als 10.000 
Seiten Umfang. Die Software wird sowohl auf 3,5-Zoll- wie 
auch auf 5,25-Zoll-Disketten geliefert. Dieser Satz besteht 
aus 63 Disketten. Die jüngste Version des MS-OS/2-SDK 
hat folgende Bestandteile: 


« MS-OS/2, Version 1.1: die erste Vorversion des 
Betriebssystems MS-OS/2 mit Presentation Manager, 
der grafischen Bedieneroberfläche für das MS-OS/2- 
System. 


® Das MS-OS/2-Programmierer-Toolkit: mit Entwick- 
lungswerkzeugen, Utilities, Beispielprogrammen und 
Referenzmaterial. 


® Die Microsoft Windows SDK-Version 2.03: jüngste Ver- 
sion des Microsoft Windows-Software-Entwicklungs- 
Kits zur Entwicklung von Applikationen unter Microsoft 
Windows 2.0 oder Microsoft Windows 386. Das Win- 
dows-Software-Entwicklungs-Kit enthält wertvolles zu- 
sätzliches Entwicklungs- und Instruktionsmaterial, das 
für die Presentation Manger-Umgebung wichtig ist. 
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® Microsoft-C und MASM, Version 5.1: die jüngste Ver- 
sion von Microsoft-C und des Microsoft Macro Assemb- 
lers für MS-OS/2, mit deren Hilfe Entwickler Applika- 
tionsprogramme für MS-OS/2 schreiben können und 
bei der Fehlersuche unterstützt werden. 


Es besteht die kostenfreie Möglichkeit, Microsofts 
Online-Entwicklungs-Unterstützungsservice in Anspruch zu 
nehmen. Außerdem erhält der Kunde acht Video-Bänder 
mit jeweils zwei Stunden Laufzeit, die nützliche Informatio- 
nen über die Entwicklung von MS-OS/2-Applikationssoft- 
ware enthalten. Alle MS-OS/2-SDK-Lizenznehmer erhal- 
ten jeweils kostenlose Aktualisierungen des SDK. 


Was Sie noch über das Transportprotokoll des 
MS-OS/2 LAN-Managers wissen sollten 


Die Microsoft GmbH veröffentlichte unlängst eine umfas- 
sende Strategie für eine Auswahl von Netzwerk-Transport- 
Protokollen mit austauschbaren Hardware-Treibern für den 
MS-OS/2-LAN-Manager, die Netzwerk-Software des neuen 
Betriebssystems MS-OS/2. Die Transportprotokolle sind 
eine Implementation des IBM-Netbeui, ISO-Transport- 
Klasse-4 sowie TCP/IP und werden sowohl für MS-DOS als 
auch für MS-OS/2 lieferbar sein. Paul Maritz, General 
Manager des Microsoft Netzwerk-Bereichs, erläuterte 
hierzu auf der ersten Advanced Network Development Con- 
ference in San Francisco: »Unsere Strategie zielt auf die 
Möglichkeit der Zusammenarbeit verschiedener MS-OS/2- 
Netzwerke durch Konzentration auf eine geringe Anzahl 
von Standardprotokollen und austauschbaren Hardware- 
Treibern. Mit Unterstützung unserer Partner bei der Ent- 
wicklung von Netzwerk-Software konzentrieren wir unsere 
Entwicklungsanstrengungen und unsere Unterstützung auf 
diese Standard-Transportprotokolle.« 

Die Datenübertragung erfolgt unter Nutzung des Stan- 
dard-MAC(Media Access Control)-Interfaces. Die Stan- 
dard-Transportprotokolle sind für das MAC-Interface 
geschrieben, das von Microsoft in Zusammenarbeit mit der 
3Com Corporation definiert wurde. Das Standard-MAC- 
Interface bietet eine einfache Möglichkeit, Treiber für 
Netzwerk-Adapterkarten zu schreiben. Es erlaubt darüber 
hinaus dem Netzwerk, mit einem Mix von Transportproto- 
kollen und Hardware zu arbeiten. So kann beispielsweise 
das Netbeui-Protokoll sowohl auf einem Ethernet- als auch 
auf einem Token-Ring-Netzwerk laufen. Als Teil der 
Zusammenarbeit zwischen Microsoft und 3Com unterstüt- 
zen die beiden Unternehmen die Entwicklungen von Trans- 
portprotokollen für Netbeui- und ISO-Datenübertragungen. 
In Zusammenarbeit mit den Unternehmen Madge Net- 
works Limited und Retix bietet die 3Com Corporation zwei 
Standard-Datenübertragungs-Produkte an. Madge Net- 
works entwickelt das IBM-Netbeui-kompatible Transport- 
protokoll, das auch den MS-OS/2-LAN-Manager in die 
Lage versetzt, mit IBM-PC Netzwerk-Produkten zusam- 
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menzuarbeiten. 3Com entwickelt die ISO-Datenübertra- 
gungs-Software, basierend auf einem Programm, das von 
Retix stammt. 3Com wird die ISO-Transport-Software 
gemäß der »Standard NetBIOS-to-ISO Mapping Specifica- 
tion« implementieren, wie sie vom TOP/NetBIOS-Archi- 
tektur-Komitee festgelegt wurde. 

Eric Benhamou, Vizepräsident der Software Products 
Division von 3Com meint: »Der MS-OS/2-LAN-Manager 
ist das Kernstück in der 3Com-’3+ Open’-Produktlinie. Die 
Verfügbarkeit von Standard-Transportprotokollen ist der 
wesentliche Punkt, um den Anforderungen unserer Kunden 
zu entsprechen«. 

Der Präsident der Firma Retix, Andy De Mari, führt 
aus: »Wir liefern die Technologie, auf deren Basis 3Com 
die ISO-Transport-Software entwickelt. Das ISO-Netzwerk- 
Protokoll wird eine größer werdende strategische Bedeu- 
tung haben, weil die Anwender Unterstützung für Stan- 
dardprotokolle fordern.« 

Robert Madge, Gründer der Madge Networks Limited: 
»Natürlich wird der MS-OS/2-LAN-Manager durch die 
Unterstützung für das IBM-Netbeui-Transportprotokoll 
verbessert. Die Kompatibilität zu dem PC-LAN-System von 
IBM wird für die Netzwerk-Anwender wesentlich sein«. 

TCP/IP wird von der Excelan Inc. geliefert. Diese Firma 
entwickelt ein TCP/IP-Transportprotokoll für den MS- 
0S/2-LAN-Manager. Kanwal Rekhi, Executive Vice Presi- 
dent of Business Development der Excelan Inc., die in die- 
sen Tagen bekanntgab, daß sie ebenfalls einen Lizenzver- 
trag für den MS-OS/2-LAN-Manager unterschrieben hat, 
dazu: »TCP/IP ist ein wichtiges LAN-Transportprotokoll, 
das heute schon eine effektive Möglichkeit der Datenüber- 
tragung in einer breiten Palette von Umgebungen bietet. 
Wir freuen uns, eng mit Microsoft zusammenzuarbeiten, 
um TCP/IP für den MS-OS/2-LAN-Manager verfügbar zu 
machen«. 

Die Implementation von TCP/IP erfolgt gemäß den 
Standard NetBIOS-t0-TCP Mapping Specification, enthalten 
in RFC1002 des Internet Activities Board. 

Microsoft wird Standardversionen dieser drei Trans- 
portprotokolle an seine LAN-Manager-OEM-Kunden lie- 
fern. IBM-Netbeui wird im zweiten Quartal 1988 verfügbar 
sein. ISO und TCP/IP stehen mit Beginn des vierten 
Quartals 1988 zur Verfügung. OEM-Kunden, die eine spe- 
zielle Version für die TCP-, IBM-Netbeui- oder ISO-Proto- 
kolle haben möchten, um zum Beispiel intelligente Netz- 
werk-Adapter zu betreiben, werden von Microsoft mit den 
Firmen Excelan, Madge oder Retix zusammengebracht. 

Microsoft liefert zusätzlich an seine OEM-Kunden eine 
MAC-Treiber-Bibliothek für eine Reihe von Netzwerk- 
Adapterkarten, einschließlich 3COM-Etherlink und IBM- 
Token-Ring. 

Das Netzwerk-Transportprotokoll ist verantwortlich für 
die Datenübertragung innerhalb des lokalen Netzwerkes 
und umfaßt Software-Funktionen von der NetBIOS-Ebene 
bis hinunter zu den Schnittstellen für die Netzwerk-Adap- 


terkarten. Es ist als ein Satz von Gerätetreibern implemen- 
tiert. Unter Microsofts DOS-basierender Netzwerk-Soft- 
ware, MS-Net, bietet jeder OEM-Lieferant seine eigenen 
Transportprotokolle an. Die OEM-Lieferanten werden 
auch weiterhin diese Option beim MS-OS/2-LAN-Manager 
haben, sie können sich nun aber auch dafür entscheiden, die 
Vorteile von Standard-Transportprotokollen zu nutzen. 
Dieses Konzept schließt nicht den Einsatz von anderen 
Transportprotokollen, wie DECNET oder XNS unter dem 
MS-OS/2-LAN-Manager aus. So plant zum Beispiel 3Com 
die Unterstützung von XNS-Protokollen auf seinen Ether- 
link-, Token-Ring- und IBM-Token-Ring-Karten als 
Wachstumsfahrt für »3+R«-Anwender an. 


Führende Software-Unternehmen unterstützen 
MS-OS/2-Netzwerkplattform 


Auf der ersten »Microsoft Advanced Network Develop- 
ment Conference« in San Francisco haben mehr als 35 füh- 
rende Software-Entwicklungsunternehmen angekündigt, 
daß sie mit mehr als 50 Anwendungsprogrammen den 
Microsoft OS/2-LAN-Manager, die LAN-Software für das 
neue Betriebssystem MS-OS/2, sowie den SOL-Server, ein 
Hochleistungs-Datenbank-Verwaltungssystem für MS- 
OS/2-Netzwerk-Server, unterstützen. Darüber hinaus 
haben weitere 29 führende Hardware-Hersteller bestätigt, 
daß sie Lizenzen für den Microsoft OS/2-LAN-Manager 
erwerben wollen. 

Einschließlich der bislang vergebenen Lizenzen sind nun 
35 namhafte Unternehmen der Computerbranche Lizenz- 
nehmer für den MS-OS/2-LAN-Manager. Darunter finden 
sich Namen wie AT&T, NCR Corporation, Tandy Corpo- 
ration, Ungermann Bass, Nokia Data, Olivetti, 3Com Cor- 
poration, Hewlett-Packard, Excelan Inc., Digital Communi- 
cations Associates Inc. und viele andere. IBM setzt darüber 
hinaus die Microsoft-OS/2-LAN-Technologie bei eigenen 
OS/2-LAN-Servern ein. 

Der MS-OS/2-LAN-Manager unterstützt drei Arten von 
Anwendungen: 


® Standard-MS-DOS- und OS/2-Anwendungen, die 
transparent in einem Netzwerk arbeiten, 

# Anwendungen, die speziell das MS-OS/2-LAN Anwen- 
dungs-Programm-Interface (APIs) nutzen, 

® Anwendungen, die den SQL-Server-Interfaces anspre- 
chen und Daten vom SQL-Server aufrufen, 


Beim ersten Typ, den Standard-MS-DOS und MS- 
OS/2-Anwendungen, erweitert der MS-OS/2-LAN-Mana- 
ger die File-Struktur und die Geräte-Schnittstellen auf das 
gesamte Netzwerk, so daß MS-OS/2-Anwendungen im 
gesamten Netz transparent unterstützt werden. Diese trans- 
parente Unterstützung bezieht sich auch auf MS-DOS- 
Arbeitsplatz-Computer und MS-DOS-Anwendungen, ein- 
schließlich Microsoft Windows-Anwendungen. 
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Der zweite Typ von Anwendungen ist speziell für den 
MS-OS/2-LAN-Manager ausgelegt. Der MS-OS/2-LAN- 
Manager bietet Anwendungs-Programm-Schnittstellen 
(APIs), die es Programmen erlauben, Netzwerk-Operatio- 
nen und Netzwerk-Ressourcen zu steuern bzw. in Anspruch 
zu nehmen. Anwendungen, die über diese Schnittstellen 
laufen, sind für die MS-OS/2-LAN-Manager-Umgebung 
optimiert. 

Der dritte Typ von MS-OS/2-LAN-Manager-Anwen- 
dungen sind solche, die als Frontend auf dem PC laufen und 
den SQL-Server unterstützen, oder die als Backend ein 
Datenbank-Verwaltungssystem darstellen. 

Der SQL-Server ist für OS/2-Netzwerke optimiert und 
arbeitet seinerseits mit den LAN-Manager Anwendungs- 
Programm-Schnittstellen. Der SOL-Server kann beispiels- 
weise als ein MS-OS/2-LAN-Manager-Service installiert 
werden, wobei er die SOL-Server-Administration verein- 
facht. 

MS-OS/2-LAN-Manager-Anwendungen sind bereits 
von führenden Software-Herstellern angekündigt worden. 
Consumers Software Inc., ein maßgebender Lieferant von 
Software für elektronische Post, kündigte mit »MS-OS/2 
Network Courier« ein intelligentes Programm an, das MS- 
DOS-, Microsoft Windows- und MS-OS/2-Arbeitsplatz- 
Computer unterstützt, die mit dem MS-OS/2-LAN-Mana- 
ger arbeiten. Network Courier wurde für das NetBIOS-Inter- 
face geschrieben, welches durch den MS-OS/2-LAN-Mana- 
ger unterstützt wird. Network Courier unterstützt darüber 
hinaus andere MS-OS/2-LAN-Manager-APIs, wie Security 
Facilities und Named Pipes. 

Als eines der führenden Software-Häuser für Buchhal- 
tungs-Software hat TLB Inc. eine neue Version seines Pake- 
tes Solomon III angekündigt. Dieses Buchhaltungspro- 
gramm wird mit einem Datenbank-Server arbeiten, um von 
den Anwendern gemeinsam benutzte Daten zu speichern 
und zur Verfügung zu stellen sowie Sicherheitsvorkehrun- 
gen, wie das Sperren von Datensätzen, zu gewährleisten. 
Die Vorteile des MS-OS/2-LAN-Managers hinsichtlich des 
Einsatzes beim »Solomon III«-Paket liegen in der MS- 
OS/2-Multitasking-Fähigkeit und der Verfügbarkeit eines 
großen Speichers auf dem Server, wobei der MS-OS/2- 
LAN-Manager gleichzeitig eine nahtlose Verbindung mit 
den auf den Arbeitsplatz-Computern laufenden Anwen- 
dungsprogrammen schafft. Die Entwickler von Solomon III 
haben außerdem weitere interessante Möglichkeiten des 
MS-OS/2LAN-Managers, wie Named Pipes, Druckerfunk- 
tionen und Netzwerk-Verwaltungsfunktionen genutzt. 

Für den SQL-Server sind eine Reihe von Arbeitsplatz- 
Computer-Anwendungen angekündigt worden. Der SOL- 
Server stellt einen erheblichen Fortschritt in der Daten- 
banktechnik dar, weil er Funktionen wie Speicherprozedu- 
ren, Trigger und einen hochentwickelten transaktionsorien- 
tierten SOL-Kern vereint. Diese Funktionen garantieren die 
Integrität der Daten und eine hohe Leistungsfähigkeit in 
einer LAN-Multiuser-Umgebung. 
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Auf der Advanced Network Development Conference 
wurden eine Reihe weiterer interessanter Anwendungen 
neben den vorab beschriebenen vorgestellt. Jede dieser 
Anwendungen machte deutlich, daß der MS-OS/2-LAN- 
Manager die richtige Wahl als Basis für lokale Netzwerke 
ist. Er bietet eine hochentwickelte, offene Plattform für die 
Entwicklung einer neuen Generation von Netzwerk-Anwen- 
dungen. Die folgende Liste stellt eine komplette Zusam- 
menstellung der Produkte dar, die auf der Advanced Net- 
work Development Conference angekündigt bzw. vorgestellt 
worden sind. Neben den Produkten sind auch deren Her- 
steller aufgeführt. Die Aufstellung schließt nicht jene hun- 
derte von MS-DOS-Anwendungsprogrammen ein, wie 
Lotus 1-2-3 und MS-Word, die heute auf MS-Net laufen 
und in gleicher Weise auf MS-OS/2-LAN-Manager-Netz- 
werken laufen werden. 


OS/2-Anwendungsprogramme 











Produkt Hersteller 
Platinum Advanced Business Microsystems 
Informix-4GL Informix Software Inc. 
Informix-SOL Informix Software Inc. 
Informix-ESQL/C Informix Software Inc. 
C-ISAM MicroPro International 
Rbase Microrim Inc. 
ORACLE für OS/2 Oracle Corporation 
Bridge/386 Softbridge Microsystems Corp. 
Bridge/286 Softbridge Microsystems Corp. 
Bridge/OS Softbridge Microsystems Corp. 
WordPerfect WordPerfect Corporation 
PlanPerfect WordPerfect Corporation 
DataPerfect WordPerfect Corporation 
WordPerfect Office WordPerfect Corporation 
DBMS und Networking 
Software WordTech Systems, Inc. 
MS-OS/2-LAN-Manager-spezifische 
Anwendungsprogramme 
Produkt Hersteller 
SuperProject Expert/?2 Computer Associates 
International Inc. 
ACCPAC Plus System Computer Associates 
Manager/2 International Inc. 
CAPS, einschließlich 
Remote Connect und 
TFD II Fault Tolerance Congent Data Technologies Inc. 
Maxess SNA Gateway 
für OS/2 Communications Solutions Inc. 
Higging Office Automation 
Software Conetic Systems Inc. 
Lanscope LAN 
Management System Connect Computer 
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Produkt Hersteller 

The Network Courier Consumers Software Inc. 

DUET Consumers Software Inc. 

Select OS/2 

Communications Server Digital Communications 
Associates 

SQLBase Gupta Technologies Inc. 

PC/Focus-MultiUser Information Builders Inc. 

SmartWare Informix Software Inc. 

Lomax Utilities J. A. Lomax Associates 

LAN Shell LAN Services Inc. 

LANtrail LAN Services Inc. 

LANfolio LAN Services Inc. 

ReferencePoint LAN Systems Inc. 

MDBS III Micro Data Base Systems Inc. 

LANscape 0S/2 Ncompass Software Inc. 

netwise TOOLS Netwise Inc, 

Sniffer Network General Corporation 


sna62 Facility 
sna0123 Facility 


Orion Network Systems Inc. 
Orion Network Systems Inc. 


netPATH SNA-3270 Pathway Design Inc. 
COAXGATE Pathway Design Inc. 
ce:Mail PCC Systems 
Add-A-Terminal Softronics Inc. 
Solomon III TLB Inc. 

Zukünftige Produkte Microsoft Corporation 


SQL-Server-Anwendungsprogramme 


Produkt Hersteller 





Paradox Ansa Software/Borland 
dBASE IV ‚Ashton-Tate Corporation 
Database Products DateEase International Inc. 
ACCESS/STAR DB/ACCESS Inc. 
PC/Foecus-MultiUser Information Builders Inc. 
GURU Micro Data Base Systems Inc. 
MDBS III Micro Data Base Systems Inc. 
KnowledgeMan/2 Micro Data Base Systems Inc. 
Workgroup Information 

Software Saros Corporation 

SQL Datenbank Software Products International 
Zukünftige Produkte Symantec Corporation 
Zukünftige Produkte Microsoft Corporation 


Vorabversion des MS-OS/2-LAN-Managers für 
viertausend MS-OS/2-Software- 
Entwicklungskit-Anwender angekündigt 


Für mehr als viertausend Besitzer des Microsoft-Software- 
Development-Kits (SDK) kündigt Microsoft für das neue 
Betriebssystem MS-OS/2 die Auslieferung einer neuen 
Vorversion des Microsoft-OS/2-LAN-Managers an. Die 
SDK-Version des MS-OS/2-LAN-Managers arbeitet mit 


MS-OS/2, Version 1.0, und der Vorversion von MS-OS/2, 
Version 1.1, die im April an alle SDK-Besitzer ausgeliefert 
wurde. Der MS-OS/2-LAN-Manager wird im Laufe des 
Juni ausgeliefert. 

Die Teilnehmer der Microsoft-Advanced-Network- 
Development-Konferenzen werden darüber hinaus eine 
Vorversion des MS-OS/2-LAN-Managers im Rahmen des 
MS-OS/2-LAN-Entwicklungspakets erhalten. 

Der MS-OS/2-LAN-Manager ist bereits bei mehr als 
hundert OEM-Kunden und ausgesuchten Anwendern 
installiert und in Betrieb. Die jetzige Aktualisierung des 
Software-Entwicklungs-Kits für MS-OS/2 entspricht dem 
Ziel von Microsoft, Entwicklern so früh wie möglich die 
Basis für die Entwicklung und Prüfung von LAN-Manager- 
Applikationen zur Verfügung zu stellen. Das neueste 
Release des MS-OS/2-Entwicklungs-Kits ist die vierte 
Aktualisierung seit der ersten Auslieferung im Juni 1987 
und wird Ende Juli 1988 verfügbar sein. Bevor die endgül- 
tige Version von MS-OS/2, Version 1.1, herauskommt, wird 
Microsoft noch weitere Aktualisierungen des Software- 
Entwicklungs-Kits ausliefern. 


Die neue Version 1.5 von Microsoft Excel für den 
Macintosh bietet eine höhere Leistung und 
vereinfacht die Applikationsentwicklung 


Microsoft hat die Auslieferung einer neuen Version von 
Microsoft Excel, dem führenden Tabellenkalkulations-Pro- 
gramm für den Apple-Macintosh, angekündigt. Die Ver- 
sion 1.5 von Microsoft Excel bietet Macintosh-Anwendern 
eine leistungsfähige und einfach zu handhabende Umge- 
bung für die Entwicklung kundenspezifischer Applikatio- 
nen. Die neue Version umfaßt nun Multitasking, Farbunter- 
stützung für den Macintosh-II, erweiterte Möglichkeiten bei 
der Erstellung von Grafiken und 44 neue Arbeitsblatt- 
Funktionen. 

Weil Tabellenkalkulations-Programme im Markt eine 
wichtige Rolle spielen, schreiben eine Reihe von unabhän- 
gigen Software-Herstellern Applikationen, die es ermögli- 
chen, mit diesen Tabellenkalkulationen auf einfache Weise 
zu arbeiten. Dies trifft in besonderem Maße auch auf 
Microsoft Excel zu. Mit den neuen umfangreichen Möglich- 
keiten von Microsoft Excel 1.5 wird die Zahl der unabhän- 
gigen Entwickler von Applikationen weiter anwachsen, so 
die Stellungnahme von Christian Wedell, Geschäftsführer 
der deutschen Microsoft GmbH. 

Die umfassenden Möglichkeiten von Microsoft Excel 1.5 
stellen eine hervorragende Umgebung für die Entwicklung 
von Applikationen für vertikale Märkte und spezifische 
Funktionen, wie zum Beispiel Lagerbestandskontrolle, dar. 
Menüs, Befehle und Dialogfelder können bei Microsoft 
Excel 1.5 vollständig anwendungsspezifisch gestaltet wer- 
den, um speziellen Anforderungen gerecht zu werden. Der 
‚Anwender kann Applikationen mit einem maßgeschnei- 
derten Interface entwickeln. 
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Excel 1.5 bietet nun Unterstützung des Multitasking des 
MultiFinder-Betriebssystems und der Farbmöglichkeiten 
des Macintosh-II. Es verwaltet nun bis zu 2.048 Daten- 
punkte (bisher 101) in einer Serie und enthält 30 neue 
Makrofunktionen und 44 neue Arbeitsblattformeln. 

Die neue Excel-Version ist so ausgelegt, daß für den 
Macintosh- und den IBM-PC dieselbe Makro-Sprache und 
ein vergleichbares Interface benutzt werden. Microsoft 
Excel 1.5 läuft auf allen AppleShare-Netzwerken und ist 
kompatibel zur gesamten Macintosh-Anwendungspro- 
gramm-Familie von Microsoft. Microsoft Excel läuft auf 
jedem Macintosh-Computer mit 512 Kbyte RAM, ein exter- 
ner Massenspeicher von 800 Kbyte Größe wird empfohlen. 

Registrierte Anwender von Microsoft Excel 1.0 erhalten 
die neue Version 1.5 zu den üblichen Update-Konditionen. 
Das Produkt wird ab Ende Juli 1988 in englisch und ab 
Ende August in Deutsch verfügbar sein. 


Mit Microsoft-File 2.0 werden Datenbank- 
Applikationen auf dem Macintosh einfacher, 
schneller und flexibler 


Microsoft hat eine wesentliche Erweiterung seines Daten- 
bank-Verwaltungsprogramms Microsoft File für den Mac- 
intosh-Plus, -SE und -II angekündigt. 

Die englische Version 2.0 arbeitet schneller, ist ein- 
facher und darüber hinaus flexibler als frühere Versionen 
dieses Datenbank-Verwaltungsprogramms. Es wurden 
mehr als 120 Format-Vorlagen hinzugefügt, um den Einsatz 
von vorgedruckten Formularen zu vereinfachen. Eine 
erweiterte Kompatibilität zur Serienbrief-Funktion von 
Microsoft Word erleichtert das Erstellen von Formbriefen, 
Serienbriefen und Etiketten. Die neue Microsoft File- 
Version unterstützt darüber hinaus die Farbdarstellungs- 
Möglichkeiten des Maecintosh-II, so daß Briefköpfe, Formu- 
lare und andere Ausdrucke nun farbig gestaltet werden 
können. 

Neu hinzugekommen ist eine Diskette mit mehr als 120 
vorformatierten Formularen, Etiketten und Bericht- 
Mustern, die den Anwender in die Lage versetzen, schnell 
zu der von ihm gewünschten Ausgabe zu gelangen. Um eine 
spezielle Ausgabe zu erzeugen, wählt der Anwender einfach 
das entsprechende Muster und gibt die Daten in das vorde- 
finierte Formular ein. Microsoft-File 2.0 enthält darüber 
hinaus eine Hilfe-Liste sowie eine kontextbezogene Online- 
Hilfsfunktion. Das Makro-Paket »AutoMac« bietet eine 
einfache Automatisierung von Routine-Aufgaben und 
Berichten. File 2.0 unterstützt auch Sonder-Papierformate 
und Mehrspalten-Etiketten, so daß Etiketten und 
Adressenlisten einfach und schnell erstellt werden können. 

Weitere Funktionen zur Verbesserung der Unterstüt- 
zung bei der Herstellung von Formularen umfassen Memo- 
Felder für lange Textpassagen, Rechenunterstützung in 
Datenfeldern sowie einen anwenderdcefinierbaren Fehler- 
wert für Feldgrenzen. Im Rahmen von Formatierungs- 
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Reports kann der File-Anwender nun Fonts und Schrift- 
arten für Absätze und ganze Texte definieren sowie Fonts 
und Größen für Überschriften und Fußnoten angeben. 

Microsoft-File 2,0 läuft auf jedem AppleShare-Netzwerk 
und unterstützt die neuesten Drucker (auch Farbdrucker) 
die durch den Macintosh-II unterstützt werden. 

Registrierte Anwender von Microsoft-File 1.0 können 
die Update-Regelung von Microsoft in Anspruch nehmen. 
Das Produkt wird Ende August 1988 in der englischen Ver- 
sion verfügbar sein. 


Ergebnisse der Microsoft-Umfrage 
unter Softwareentwicklern 


Im März dieses Jahres führte Microsoft ein Umfrage unter 
Softwareentwicklern durch. Gefragt wurde unter anderem 
nach der hauptsächlichen Verwendung von Programmier- 
sprachen, Zielbetriebssystem für die Entwicklung, Kommu- 
nikationsmöglichkeiten, Vorschläge für die technische 
Unterstützung durch Microsoft und Arten der Weiterbil- 
dung. Etwa 1000 Fragebögen gingen ausgefüllt bei 
Microsoft ein. Der weitaus größte Teil (ca. 1/3) der Ent- 
wickler sitzt in Firmen mit eigener Entwicklung, zu den 
nächstgrößeren Gruppen gehören Softwarehäuser, Hoch- 
schulen und Unternehmensberater. Der weitaus größte Teil 
(ca. 60%) entwickelt Software für MS-DOS, an zweiter 
Stelle steht mit ca. 10% Microsoft Windows; OS/2 und 
andere Betriebssysteme (Xenix, Macintosh) liegen derzeit 
um die 5%. An Programmiersprachen werden am meisten 
Cobol, C, Fortran, BASIC und Pascal eingesetzt (in dieser 
Reihenfolge). Es werden alle wesentlichen Kommunika- 
tionseinrichtungen genutzt (BTX, Koppler, Modem, Datex- 
P), bevorzugt werden jedoch Modems. Für den Microsoft- 
Support wurden Erweiterungen in Richtung mehr Informa- 
tionen auf Papier und Diskette, Anfragemöglichkeiten über 
Modem und Zugriff auf eine zentrale Support-Datenbank 
vorgeschlagen. Die meisten Entwickler sind durchaus 
bereit, für solche Verbesserungen auch zu zahlen. 

Unter den Einsendern des Fragebogens wurden 10 
Exemplare von Microsoft Excel verlost. Microsoft gratuliert 
den glücklichen Gewinnern: 


= Detlev Bock, Petrikirchstr. 36, 3400 Göttingen 
GSE GmbH, Pixistr. 2, 8000 München 80 
Hermes Precisa International SA, Andr& Stachli, CH 
Yverdon-Les-Bains 
= Otto F. Dittmar, Riedsaumstr. 22, 6700 Ludwigshafen 
= ProCom GmbH, Claudia Geilenkirchen, Luisenstr. 41, 
5100 Aachen 
= Adapt Software/Hardware, Franz Reisinger, Staudgasse 
7/2/9, A-1180 Wien 
Reinhold Werth, Sternstr. 17, 8000 München 22 
Dr. R. Herzig, 91, Rue de la Servette, CH-1202 Genf 
Jean-Pierre Huber, 19, Rue Maunoir, CH-1207 Genf 
Polymot GmbH, Zürcherstr. 23, CH-8640 Rapperswil 
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Die Grafikprogrammiersch: le von OS/2: 





GPI: Eine Einführung in Präsentationsbereiche 


Programmierer, die bereits Erfahrung mit 
Microsoft Windows haben, werden feststellen, 
daß der größte Teil des OS/2 Presentation 
Managers bereits bekanntes Gebiet ist. Die Be- 
reiche Fensterverwaltung und Benutzerschnitt- 
stelle des Presentation Managers stammen ganz 
offensichtlich aus Windows und viele Fenster- 
meldungen sind identisch. 


Die Grafikprogrammierschnittstelle (Graphics Program- 
ming Interface, GPI) ist jedoch im wesentlichen neu und 
bietet einige sehr wichtige Erweiterungen gegenüber dem 
Graphics Device Interface (GDI) von Windows. GPI 
stammt im wesentlichen von IBMs Graphical Data Display 
Manager (GDDM) und vom 3270 Graphics Control Pro- 
gram (GCP) ab, wobei einige Fähigkeiten wie Bitmaps und 
Regionen aus Windows stammen. In GPI findet sich auch 
der Einfluß vieler anderer Grafikschnittstellen, vom Gra- 
phical Kernel System (GKS) bis PostScript. 

Eine der ersten Hürden bei der Annäherung an GPI ist 
das Verständnis des Konzepts des Präsentationsbereichs 
(presentation space oder kurz PS). Was es so schwierig 
macht ist, daß der Presentation Manager drei verschiedene 
Arten von Präsentationsbereichen unterstützt, den »Cached 
Mikro-PS,« den »Mikro-PS,« und den »normalen PS«. 

Welche Art von Präsentationsbereich Sie für Ihre An- 
wendung wählen, hängt von zahlreichen Faktoren ab, von 
denen einige hier beschrieben werden sollen. 

Das Thema wird noch interessanter, wenn Sie berück- 
sichtigen, daß die Art des Präsentationsbereichs zu einem 
gewissen Grad mitbestimmt, wie eine Presentation Mana- 
ger-Anwendung zum Zeichnen strukturiert wird. Ich werde 
dies anhand von drei Programmen demonstrieren, 
CACHEDPS, MICROPS und NORMALPS, wobei jedes 
einzelne eine der drei vorhandenen Arten von Präsentati- 
onsbereichen verwendet. 

Jedes Programm zeigt die einfache Grafik an, die in Bild 
1 zu sehen ist. Der String »Graphics Programming Inter- 
face« wird in der Mitte des Fensters gezeichnet mit ge- 
punkteten Linien von den Ecken des Strings zu den Ecken 
des Fensters. Der Text und die gepunkteten Linien werden 
rot angezeigt. 


Die Zeichenfunktionen des GPI 


Bevor ich näher auf die Präsentationsbereiche eingehe, 
wollen wir einen schnellen Blick auf die Funktionen werfen, 
die diese drei Programme zum Zeichnen des Textes und 
der gepunkteten Linien verwenden. Das Programm 
CACHEDPS.C ruft die GPI-Zeichenfunktionen in seiner 
Funktion ClientWndProc bei der Bearbeitung der Mel- 
dung WM_PAINT auf. 





Bild 1: Das Programm CACHEDPS unter dem OS//2 Presen- 
tation Manager. 


Viele der GPI-Zeichenfunktionen benötigen einen 
Punkt aus X- und Y-Koordinaten, der der Funktion als eine 
Struktur vom Typ POINTL übergeben wird. Die Struktur 
POINTL wird in der Header-Datei OS2DEF..H etwa so defi- 
niert: 





typedef struct _POINTL 


LONG x ; 
LONG y ; 


} 
POINTL ; 





Der Datentyp LONG ist einfach eine 32-Bit unsigned long 
Ganzzahl. Um eine POINTL-Struktur zu definieren, können 
sie so vorgehen: 





struct _POINTL ptl ; 





Oder noch einfacher: 





POINTL pt1 ; 











Gewöhnlich beginnen POINTL-Variablen mit dem Prä- 
fixptl. 

(Ein großer Unterschied zwischen GPI und anderen 
höheren Grafiksprachen ist, daß GPI keine Fließkomma- 
zahlen verwendet. Dies wurde aus Leistungsgründen so 
gemacht - Fließkommaberechnungen auf PCs sind immer 
noch nicht schnell genug für ausgesprochen interaktive 
grafische Systeme wie den Presentation Manager.) 

GPI verwendet das Konzept der aktuellen Position. Um 
eine Linie zu zeichnen, besteht der erste Schritt darin, die 
aktuelle Position auf den Anfang der Linie einzustellen. 
Dazu müssen die Koordinatenwerte den X- und Y-Feldern 
der Struktur POINTL zugewiesen und dann die Funktion 
GpiMove aufgerufen werden: 
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tr. 
iy=. 








GpiMove Chps,&ptl) ; 





Ich werde den Parameter hps von GpiMove später er- 
klären. GpiMove zeichnet nicht; damit wird nur die aktuelle 
Position eingestellt. Um die Linie zu zeichnen, werden die 
Felder der Struktur auf den Endpunkt eingestellt und dann 
GpiLine aufgerufen: 





PELK= u; 
pilye.. 


GpiLine (hps,&ptl) ; 








Die Funktion GpiLine bewegt auch die aktuelle Posi- 
tion auf den angegebenen Punkt. 

Es ist eindeutig ziemlich umständlich, vor dem Aufruf 
von GpiMove oder GpiLine die beiden Felder der Struk- 
tur POINTL zu belegen. Sie werden jedoch feststellen, daß 
die Verwendung einer Struktur für die Darstellung von 
Punkten für die Syntax der GPI-Funktionen eine schöne 
saubere Konsistenz bedeutet. So hat beispielsweise die 
Funktion GpiQueryCurrentPosition, die die aktuelle 
Position abfragt, die gleiche Syntax wie GpiMove: 





GpiQueryCurrentPosition (hps,äptl) ; 








Bei der Rückkehr von der Funktion enthält die Struktur 
pt1 die Koordinaten der aktuellen Position. 

Die Verwendung eine Struktur für die Punkte ermög- 
licht eine Syntaxkonsistenz auch bei den GPI-Funktionen, 
die mehrere Punkte erfordern. Eine solche Funktion ist 
GpiPolyLine, die eine Reihe von Linien ausgehend von 
der aktuellen Position zeichnet. Ein Array von POINTL- 
Strukturen wird so definiert: 





POINTL apt1 [15] ; 





Für den Aufruf von GpiPolyLine werden die Anzahl 
der Punkte und der Arrayname benötigt: 





GpiPolyLine (hps,15L, aptl) ; 





Dieser Aufruf von GpiPolyLine ist im wesentlichen 
identisch mit: 








for 1 =8;1< 15 ; 1) 
GpiLine (hps,apti + 1) ; 








Die Punkte bei GPI-Funktionen werden in »Weltkoordi- 
naten« angegeben. Obwohl GPI mehrere Umsetzungsmög- 
lichkeiten von Welt- in Pixelkoordinaten bietet, werde ich 
hier noch nicht auf diese Umsetzungen eingehen. Standard- 
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mäßig sind die Weltkoordinaten Einheiten von Pixeln rela- 
tiv zur linken unteren Ecke des Fensters. Werte auf der X- 
Achse (horizontal) erhöhen sich nach rechts; Werte auf der 
Y-Achse (vertikal) erhöhen sich nach oben. 

CACHEDPS.C verwendet die Funktion GpiChar- 
StringAt um einen Textstring anzuzeigen: 





GpiCharStringAt (hps, &ptl,ITextLength,cText) ; 








Unter normalen Umständen wird die Grundlinie der 
linken Seite des ersten Zeichens an dem Punkt angesetzt, 
der in der Struktur ptl angeben wird. Der Parameter 
cText ist ein Zeiger auf ein Zeichenarray, und 1Text- 
Length ist die Länge des Strings. Der folgende Code zeigt 
zum Beispiel den Text »Hello« am Punkt (10, 10) an: 





ptl.x = 18; 
ptl.y = 18; 


GpiCharStringAt (hps, &ptl,5L,«Hello«) ; 





Standardmäßig verwendet GPI als Schrift die normale 
Systemschrift, die gleiche Schrift also, die in den Titelzeilen, 
Menüs und Dialogboxen des Presentation Managers ver- 
wendet wird. 


GPI-Attribute 


CACHEDPS.C ruft zwei Funktionen auf, um die Attribute 
einzustellen, die GPI beim Zeichnen verwendet. Noch bevor 
irgendetwas gezeichnet wird, ruft das Programm GpiSet- 
Color auf: 





GpiSetColor (hps,CLR_RED) ; 








Das bewirkt, daß jeder Text und alle Zeilen, die nach 
dieser Funktion aufgerufen werden, die Farbe rot erhalten. 
Bevor die vier Zeilen angezeigt werden, ruft CACHEDPS.C 
eine weitere Attributfunktion auf, um den Linientyp 
gepunktet (dot) einzustellen: 





GpiSetLineType (hps, LINETYPE_DOT) ; 











GPI verfügt auch über Funktionen, die Informationen 
vom System abfragen. Eine der Abfragefunktionen, die in 
CACHEDPS.C verwendet wird, ist GpiQueryTextBox. 
Diese Funktion füllt ein POINTL-Array mit den Positions- 
koordinaten der vier Ecken eines imaginären Rahmens, der 
diesen speziellen Zeichenstring umgeben würde, wenn er 
am Punkt (0,0) ausgegeben worden wäre. Das Programm 
CACHEDPS verwendet diese Informationen, um vier 
Linien zu zeichnen. 

Zu Beginn der Verarbeitung von WM_PAINT ruft 
CACHEDPS.C die Funktion GpiCreateLogColorTable 
auf. In der Version des Presentation Managers, die ich für 
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hps = WinBeginpaint (hund, NULL,NULL) ; 
< hier werden GPI-Funktionen verwendet > 


WinEndPaint (hps) ; 





Ein Cached-Mikro-PS hat mehrere wichtige Charakte- 
ristiken. Erstens ist ein Cached-Mikro-PS immer mit dem 
Bildschirm verbunden, oder genauer mit einem Fenster auf 
dem Bildschirm. Dadurch kann der Cached-Mikro-PS ein- 
fach verwendet werden (WinGetPS benötigt nur einen 
Parameter), er ist aber auch auf den Bildschirm beschränkt. 

Zweitens werden alle Attribute des Präsentationsbe- 
reichs auf ihre Standardwerte eingestellt, wenn mit 
WinGetPS oder WinBeginPaint eine Handle angefordert 
wird. Darum stellt CACHEDPS.C die Farbe auf rot und den 
Linientyp auf gepunktet ein, wenn es die Meldung wM_ 
PAINT verarbeitet. 

Schließlich zeichnet ein Programm, daß einen Cached- 
Mikro-PS verwendet, gewöhnlich in Pixeleinheiten. Das 
kann durch einige Aufrufe bestimmter GPI-Funktionen ge- 
ändert werden, es ist jedoch nicht so einfach, als wenn ein 
Programm mit GpiCreatePS seinen eigenen Präsenta- 
tionsbereich anlegt. 

Windows-Programmierer werden feststellen, daß 
CACHEDPS ähnlich strukturiert ist, wie ein Windows-Pro- 
gramm. Wenn Sie ein Programm von Windows auf den Pre- 
sentation Manager umsetzen, werden Sie wahrscheinlich 
den Cached-Mikro-PS verwenden, um die Umsetzung zu 
erleichtern. 


Die Meldung WM_PAINT 


CACHEDPS erledigt alle Zeichenvorgänge bei der Verar- 
beitung der Meldung WM_PAINT. Die korrekte Handha- 
bung der Meldung WM_PAINT ist von enormer struktureller 
Bedeutung, sowohl in Windows- als auch in Presentation 
Manager-Programmen. 

Eine Fensterprozedur erhält die Meldung WM_PAINT 
immer dann, wenn ein Fensterbereich ungültig geworden 
ist, was bedeutet, daß dieser Bereich nicht länger das 
enthält, was das Programm ursprünglich dort gezeichnet 
hat. Wenn ein Teil eines Fenster bedeckt worden ist und 
dann wieder frei wird, schickt der Presentation Manager die 
Meldung WM_PAINT an das Fenster. Eine Fensterprozedur 
kann die Meldung WM_PAINT auch erhalten, wenn die Fen- 
stergröße verändert wurde. 

Auch wenn ein Presentation Manager-Programm fast 
jederzeit in einem Fenster zeichnen kann, muß das Pro- 
gramm bei Erhalt der Meldung WM_PAINT jedoch auch 
fähig sein, das ganze Fenster zu aktualisieren. Viele Pro- 
grammierer bewerkstelligen dies, indem sie alle Fensteraus- 


gaben bei Erhalt der Meldung WM_PAINT durchführen und 
sonst nicht. Wie Sie noch sehen werden, ist die Behandlung 
der Meldung WM_PAINT bei einem normalen PS einfacher. 


Der Mikro-PS 


Da der Cached-Mikro-PS immer mit einem Fenster auf 
dem Bildschirm verbunden ist, kann ein Cached-Mikro-PS 
nicht dazu verwendet werden, auf einem anderen Ausgabe- 
gerät zu zeichnen, zum Beispiel einem Drucker oder 
Plotter. Um einen Drucker oder Plotter zu verwenden, 
müssen Sie entweder einen Mikro-PS oder einen normalen 
PS anlegen. Ein Programm kann einen Mikro-PS auch zum 
Zeichnen im Programmfenster verwenden. Das Programm 
MICROPS in Listing 2 zeigt, wie dies gemacht wird. 

MICROPS.C legt den Präsentationsbereich an, indem es 
GpiCreatePS bei der Bearbeitung der Meldung WM_ 
CREATE in ClientWndProc verwendet. Die Angabe GPI- 
T_MICRO in der Funktion GpiCreatePS bedeutet für GPI, 
daß ein Mikro-PS angelegt werden soll. GpiCreatePS 
benötigt auch noch eine Handle für einen Displaykontext, 
mit dem der Präsentationsbereich verbunden wird. Bei 
einem Bildschirmfenster wird diese Handle für den Display- 
kontext mit WinOpenWindowDC abgefragt: 


Der Präsentationsbereich beinhaltet eine imaginäre 
Zeichenoberfläche, die Präsentationsseite genannt wird 
(presentation page). (Ich verspreche, daß das der letzte 
neue Ausdruck ist, den ich hier verwende.) Die Größe und 
Einheiten der Präsentationsseite werden mit der Funktion 
GpiCreatePS definiert. Die Größe der Seite wird mit der 
Struktur SIZEL eingestellt. Wenn die Felder cx und cy auf 
0 gesetzt werden, erhält die Seite die gleiche Größe, wie der 
ganze Bildschirm. Der Name PU_PELS gibt an, daß die 
Koordinaten der Seite in Pixeleinheiten angegeben werden. 
Stattdessen kann auch einer der Namen in Tabelle 1 für 
andere Einheiten verwendet werden. 





hde = WinOpenWindowDG (hund) ; 








Name für 

Seiteneinheiten Einheiten 
PU_ARBITRARY Pixel (mit Anpassung) 
PU_PELS Pixel 

PU_LOMETRIC 0.1 Millimeter 
PU_HIMETRIC 0.01 Millimeters 
PU_LOENGLISH 0.01 Inch 
PU_HIENGLISH 0.001 Inch 
PU_TWIPS 1/1440 Inch 


Tabelle 1: Die Namen, die in der Funktion GpiCreatePS 
zur Einstellung der Einheiten der Präsentationsseite verwendet 
werden können. 
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diesen Artikel verwendet habe, ist die Standardhintergrund- 
farbe schwarz und die Standardvordergrundfarbe weiß. Die 
Funktion GpiErase löscht das Fenster also auf schwarz. 
Der Aufruf von GpiCreateLogColorTable in 
CACHEDPS kehrt dies um, so daß die Standardhinter- 
grundfarbe weiß und die Standardvordergrundfarbe 
schwarz ist. Ob diese Funktion auch noch in der endgültigen 
Version des Presentation Managers benötigt wird, ist 
momentan noch nicht sicher. 

Die Aufrufe von GpiRestorePS, GpiSavePS und 
GpiResetPS in CACHEDPS.C bei der Meldung WM_PAINT 
sind Patches, die einige Fehler in meiner Version des 
Presentation Managers vermeiden sollen. Diese Funktionen 
sollten nicht notwendig sein, wenn der Presentation 
Manager seine endgültige Form hat. 


PS und DC 


Der erste Parameter bei jeder GPI-Funktion in CACHED- 
PS.C ist die Variable hps. Diese Variable wird als Typ HPS 
definiert, als Handle auf einen Präsentationsbereich (pre- 
sentation space oder kurz PS). 

Bevor ein Presentation Manager-Programm etwas auf 
dem Bildschirm zeichnen kann, muß es entweder einen Prä- 
sentationsbereich anlegen oder einen Präsentationsbereich 
verwenden, der bereits vom Presentation Manager angelegt 
wurde. Wie man dies macht, hängt von der Art des Präsen- 
tationsbereichs ab, für die Sie sich entscheiden. 

Ein Präsentationsbereich ist im Grunde eine interne 
Datenstruktur des Presentation Managers. Alle Attribute 
eines Präsentationsbereichs - die aktuelle Position, die 
dezeitigen Hinter- und Vordergrundfarben, die aktuelle 
Linienart, Umsetzungen und mehr - werden hier gespei- 
chert. Bei einem normalen PS kann der Präsentations- 
bereich auch Sammlungen von GPI-Funktionsaufrufen auf- 
nehmen. 

Ein Windows-Programmierer wird auf den ersten Blick 
sicherlich annehmen, daß der Präsentationsbereich dem 
Windows-Displaykontext (display context: DC) entspricht, 
doch sie sind in Wirklichkeit gänzlich verschieden. Tatsäch- 
lich beinhaltet der Presentation Manager auch das Konzept 
des Displaykontexts. 

Beim Presenation Manger beschreibt der Displaykontext 
gewöhnlich ein physisches Ausgabegerät, zum Beispiel den 
Bildschirm, einen Drucker oder einen Plotter. Ein Display- 
kontext kann auch ein Speicherbereich sein, der so verwen- 
det wird, als ob es sich dabei um ein Ausgabegerät handelt; 
es kann auch eine Metadatei sein. Sie können sich einen 
Displaykontext am besten als zusammengesetzt aus einem 
Ausgabegerät und einem Gerätetreiber vorstellen. 

Ein Präsentationsbereich impliziert keine Art von 
Ausgabegerät. Statt dessen muß ein Präsentationsbereich 
mit einem bestimmten Displaykontext verbunden werden. 
Der Grund für die Trennung von Präsentationsbereich und 
Displaykontext wird später deutlich werden. Die konzeptio- 
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nelle Beziehung zwischen einer Anwendung, dem Präsenta- 
tionsbereich und dem Displaykontext ist in Bild 2 zu sehen. 

Von den drei verschiedenen Arten von Präsentations- 
bereichen, die vom Presentation Manager unterstützt 
werden, ist der normale PS (gelegentlich auch der volle PS 
genannt) der vielseitigste, der Mikro-PS folgt an zweiter 
Stelle und der unflexibelste ist der Cached-Mikro-PS. 

Um einen normalen oder Mikro-PS zu verwenden, muß 
ein Programm mit der Funktion GpiCreatePS einen Prä- 
sentationsbereich anlegen. Genaugenommen sind dies die 
beiden einzigen Arten von Präsentationsbereichen, die von 
GPI unterstützt werden. Der Cached-Mikro-PS ist dank der 
Komponente des Presentation Managers verfügbar, die die 
Fenster und Benutzerschnittstellenfunktionen enthält, 
gelegentlich auch »Win«- oder »User«-Komponenten ge- 
nannt. Der Presentation Manager legt diesen Mikro-PS für 
Sie an. 


Der Cached-Mikro-PS 


Das Programm CACHEDPS in Listing 1 verwendet einen 
Cached-Mikro-PS. (Nähere Informationen über Cached- 
Mikro-PS sind im Microsoft Operating System/2 Software 
Developing Kit, Presentation Manager Specification, Vol. 1, 
S. 210 zu finden.) Ein Programm kann eine Handle auf 
einen Cached-Mikro-PS erhalten, indem es WinBegin- 
Paint oder WinGetPS aufruft. CACHEDPS.C verwendet 
beide Funktionen. 

Die Funktion WinGetPS kann bei der Verarbeitung der 
Fenstermeldung verwendet werden. Wenn Sie den Präsen- 
tationsbereich nicht mehr benötigen, wird er durch einen 
Aufruf von WinReleasePS wieder freigegeben: 





Ihps = WinGetPS (hund) ; 
< hier werden GPI-Funktionen verwendet > 


WinReleasePS (hps) ; 





CACHEDPS ruft WinGetPS bei der Meldung WM_ 
CREATE auf. Die einzige GPI-Function, die das Programm 
zu diesem Zeitpunkt aufruft, ist GpiQueryTestBox, 
CACHEDPS braucht die Dimensionen der Zeichenbox nur 
einmal abfragen, da die Höhe und Breite des Textstrings 
beim Ablauf des Programms nicht verändert werden. 

Die Funktionen WinGetPS und WinReleasePpS 
müssen bei der Bearbeitung einer Meldung paarweise 
aufgerufen werden. Rufen Sie niemals WinGetPS bei der 
Bearbeitung einer Meldung und WinReleasePS bei der 
Bearbeitung einer anderen auf. 

Bei der Meldung WM_PAINT ruft man WinBeginPaint 
auf, um eine Handle für einen Cached-Mikro-PS zu 
erhalten, und WinEndPaint, um sie freizugeben: 
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Die Verwendung einer Seite mit Pixelkoordinaten ist 
meistens die beste Vorgehensweise für einfache Grafikaus- 
gaben. Informationen, die vom Fenstersystem des Presenta- 
tion Managers übergeben werden, beispielsweise die Größe 
des Fensters bei der Meldung WM_SIZE, wird immer in 
Pixeleinheiten angegeben, ganz unabhängig von der Größe 
der Präsentationsseite. Diese Koordinaten und Größen 
müssen dann mit GpiConvert in die verwendeten Seiten- 
einheiten umgerechnet werden. 

Der Präsentationsbereich, der von GpiCreatePS über- 
geben wird, ist gültig, bis der Präsentationsbereich mit 
einem Aufruf von GpiDestroyPS gelöscht wird. MICRO- 
PS löscht den Präsentationsbereich bei der Bearbeitung der 
Meldung WM_DESTROY, die die letzte Meldung ist, die eine 
Fensterprozedur erhält. Bis dahin muß der Wert hps bei 
allen WA_PAINT- und WM_STZE-Meldungen verwendet wer- 
den, deshalb wird er in einer statischen Variablen gespei- 
chert. 

Es ist zu beachten, daß MICROPS die Farbe und den 
Linientyp bei der Bearbeitung der Meldung WM_CREATE 
einstellt und nicht bei WM_PAINT. Der Mikro-PS existiert 
bis er explizit gelöscht wird, jedes GPI-Attribut, daß ein 
Programm einstellt, bleibt im Präsentationsbereich einge- 
stellt, bis es verändert wird. Im Gegensatz dazu wird ein 
Cached-Mikro-PS immer auf Standardwerte zurückgesetzt, 
wenn ein Programm ihn anfordert. 

Die Syntax der Funktion WinBeginPaint für einen 
Mikro-PS unterscheidet sich ein wenig von der für einen 
Cached-Mikro-PS. Anstatt WinBeginPaint zu verwenden, 
um eine Handle für den Präsentationsbereich zu erhalten, 
wird die vorhandene Handle als zweiter Parameter an die 
Funktion übergeben. (In der Version des Presentation 
Managers, die ich für diesen Artikel verwende, arbeiteten 
WinBeginPaint und WinEndPaint noch nicht richtig, 
deshalb stehen sie als Kommentar in MICROPS.C.) 

Windows-Programmierer aufgepaßt! Sie werden es 
sicherlich für selbstverständlich halten, bei Verwendung 
eines Cached-Mikro-PS während der WM_PAINT-Meldung 
folgendes zu tun: 





hps > WinBeginPaint (hund, NULL,NULL) ; 
< nit Standardfarben zeichnen > 
Gpisetfolor (hps,CLR_RED) ; 

< at rot zeichnen > 


WinEndpaint (hps) ; 





Wenn Sie auf einen Mikro-PS umstellen, werden Sie den 
Code wahrscheinlich folgendermaßen ändern: 
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tion Manager 





WinBeginPaint (hund,hps, NULL) ; 


< sit Standardfaben zeichnen > 


GpiSetColor (hps,CLR_RED) ; 
< sit rot zeichnen > 


WinEndPaint (hps) ; 








Dies funktioniert einwandfrei bei der ersten WM_PAINT- 
Meldung, doch nicht bei den folgenden Meldungen, da die 
Farbe immer noch auf rot eingestellt ist. Beachten Sie, daß 
der Mikro-PS alle GPI-Attribute beibehält, bis Sie sie 
wieder ändern. Sie können solche Probleme vermeiden, 
indem Sie GpiSavePS und GpiRestorePS verwenden, 
um die GPI-Einstellungen zu speichern und wiederherzu- 
stellen: 





Tr —t 


WinBeginPaint (hund,hps, NULL) ; 
< alt Standardfarben zeichnen > 


iSavePs (hps) ; 
Ghisettolor nos cLR.RED) ; 


< sit rot zeichnen > 


iRestorePS (hps,-IL) ; 
MinEndbeint rs i 





Sie können die Farbe auch am Ende der WM_PAINT- 
Verarbeitung explizit auf den Standardwert zurücksetzen: 





MnBoginpaint (hund, hps, NULL) ; 
< it Standardfarben zeichnen > 
GpisetCnlor (hps,CLR_RED) ; 

< nit rot zeichnen > 


GpiSetColor (hps, CLR_DEFAULT) ; 
inEndPaint (hps) ; 














Beim Vergleich der Programme CACHEDPS.C und 
MICROPS.C zeigt sich nur eine geringfügige Strukturände- 
rung: Zwei GPI-Attributfunktionen, die in CACHEDPS bei 
der Meldung WM_PAINT aufgerufen werden, werden in 
MICROPS bei der Meldung WM_CREATE behandelt. Eine 
wirkliche Strukturänderung findet erst statt, wenn Sie auf 
den normalen PS umsteigen. 


Der normale PS 


Der Mikro-PS ermöglicht einem Programm nur den Zugriff 
auf eine Untermenge der GPI-Funktionen. Auch wenn es 
eine schr umfangreiche Untermenge ist und alle wichtigen 
Funktionen dazugehören, beinhaltet der Mikro-PS nicht die 
Funktionen, die mit GPI-Segmenten zu tun haben; diese 
werden nur bei einem normalen PS unterstützt. 

Ein Segment (nicht zu verwechseln mit einem Speicher- 
segment der 80286-Mikroprozessor-Architektur) ist eine 
gespeicherte Sammlung von Grafikzeichen- und Attribut- 
befehlen. Man öffnet ein Segment, ruft mehrere GPI- 
Funktionen auf und schließt das Segment wieder. Alle 
Funktionen werden in dem Segment gespeichert. Man kann 
dann diese Befehle auf dem Ausgabegerät zeichnen lassen, 
indem eine von mehreren Funktionen, wie zum Beispiel 
GpiDrawChain, aufgerufen wird. Das Programm NOR- 
MALPS in Listing 3 bietet Ihnen einen kleinen Vorge- 
schmack auf Segmente. 

Die Grafikausgabe von NORMALPS hängt nur von der 
Größe des Fensters ab. Deshalb wird bei der Meldung 
WM_SIZE mit einem Aufruf von GpiOpenSegment ein 
Segment angelegt. Die Attribut- und Zeichenbefehle wer- 
den geanuso aufgerufen, wie in den beiden früheren Pro- 
grammen. Doch diese Grafikbefehle werden nicht sofort 
angezeigt; sie werden nur im Segment gespeichert. Bei der 
Meldung WM_PAINT wird das Segment mit einem Aufruf 
von GpiDrawChain angezeigt. Ganz eindeutig vereinfacht 
dies die Bearbeitung der Meldung WM_PAINT erheblich. 

Man kann in einem Programm viele Segmente anlegen; 
Sie werden als Teil des Präsentationsbereichs gespeichert. 
Ein Segment kann verkettet oder nicht verkettet sein. Die 
Hauptkette besteht aus allen verketteten Segmenten; Gpi- 
DrawChain zeichent alle Segmente in der Hauptkette. 

Nicht verkettete Segmente können von anderen Seg- 
menten aufgerufen werden. Wenn ein nicht verkettetes Seg- 
ment aufgerufen wird, können die Positionskoordinaten, die 
in allen Zeichenkommandos verwendet werden, umgesetzt, 
skaliert oder rotiert werden, was besonders für plastische 
Grafiken sehr nützlich ist. 

Man kann Segmente bearbeiten, die Reihenfolge verän- 
dern, in der die Segmente in der Hauptkette gezeichnet 
werden und prüfen, ob sich ein in einem Segment gezeich- 
netes Objekt innerhalb eines angegebenen Radius um einen 
bestimmten Punkt befindet. Dies ist vor allem dann sehr 
hilfreich, wenn man prüfen will, ob ein Objekt mit der Maus 
angeklickt wurde. 


ntation Manager 





Neben der Unterstützung von Segmenten hat ein nor- 
maler PS einen weiteren Vorteil gegenüber dem Mikro-PS. 
Er ist der einzige Präsentationsbereich, der mit einem 
anderen Displaykontext verbunden werden kann; das be- 
deutet, man kann die Verbindung des Präsentationsbereichs 
mit dem Bildschirm lösen und ihn dann mit dem Drucker 
verbinden. Da die Segmente Teil des Präsentationsbereichs 
sind, brauchen sie nicht neu erstellt werden. Die Segmente 
sind sofort fertig für die Ausgabe auf dem Drucker. 

Natürlich ist die Verwendung von Segmenten in 
NORMALPS übertrieben, wie das auch bei vielen anderen 
kleinen Presentation Manager-Programmen der Fall sein 
wird. Die Grundregel lautet, daß man den einfachsten 
Präsentationsbereich verwenden sollte, der für eine 
Aufgabe angemessen ist. Wenn Sie alles, was Sie machen 
wollen, mit einem Cached-Mikro-PS erreichen können, 
verwenden Sie ihn. Schleppen Sie nicht das komplette 
Reisegepäck für eine Woche auf einer Tagesreise mit sich 
herum. 

Charles Petzold 
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Bild 2: Die Beziehungen zwischen einer Anwendung, dem 
Präsentationsbereich und dem Displaykontext. 
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CACHEDPS: Die Make-Datei für CACHEDPS 






PR RRORERE Feet switch (msg) 
pr CACHEDPS Nake-Datei 2 WM_CREATE: 
ee hps = WinGetPS (hund) ; 
„obj_: cachedps.c (QueryTextBo: fextLer ;2Text, 
ed -e -GAsu -H3 -2Zp cachedps.c L- or GN eantıTertber) ; 


R r „obj cachedps.def % 
een. tEH NUL, slibep 052, cachedps ers Lipel? 


case WM_SIZE: 
ex@lient = LOUSHORT (mp2) ; 
EyClient = HIUSHORT (mp2) } 


a eeBox LDETBOX. BOTTOMRIGHTI. 
Be 
abtiTentgor TXTBOX_BOTTOMLEFT].x) / 2 ; 
tlTextStart.y = (cyClient - 
® AptIToetBox® TIKTBOX TOPLEFT! 
apt1TextBox EnKBoICBoroHLERN yv2: 


"Beispiel für Cached-I Mikro-S for = 8 ; sIndex < 4 ; sIndex ++) 





CACHEDPS.C: Der Quellcode von CACHEDPS 








aptlLineStart [sIndex] =» aptITextBox [sIndex] ; 
#define INCL_GPI aptlLineStart [sIndex].x +” ptlTextStart.x ; 

aptlLineStart [sIndex].y += ptlTextStart.y ; 
‚Ainclude <052.h> } 

break ; 

case WM_PAINT: 
ULONG EXPENTRY ClientWndProc (HWND, USHORT, ULONG, ULONG) ; hps = WinBeginpaint (hund, NULL, NULL) ; 
int main (vold) GpiSavePS (hps) ; /" Patch w/ 
{ GpiResetPS (hps, GRES_ATTRS) ; /w Patch #/ 


le u szClientClass [] = "CachedPS" ; 
EEE ÄNDREB, BL {hps, LCOL_RESET, 


"Q It BL, AL, alColorData) ; 
HUND hundFrame, hwndClient ; 

MSG qusg ; GpiErase (hps) ; 

hab = WinInitialize (8) ; GpiSetColor (hps, CLR_RED) ; 


haq = WinCreatelisgQueue (hab, 8) ; 
Gpi@arStringat (hps; pklTextstart, 
NinRegisterClass (hab, saClientClass, ClientkndProc, iTextLength, szText) ; 
(CS_SIZEREDRAN 


E GpiSetLineType (hps, LINETYPE_DOT) ; 





hwndFrame = ee (HWND DESKTOP. 
WS_VISIBLE | BR a 1 FS_TITLEBAR 


I FS_SYSMENU I FSMINMAX, Gpilove jtes, aptlLineStart+TXTBOX_BOTTONLEFT) ; 
szClientClass, "Cached Micro-PS”, ptl.x=B; 
8L, NULL, 8, &hwndClient) ; tl.y = & ; 
{Line (hps, &ptl) ; 
while (Wintet! (hab, &qnsg, NULL, 8, 8)) 
HinDispat« (hab, &qusg) ; 


rl te „aptlLineStart+TXTBOX_BOTTOMRICHT) ; 
HinDestroykindow (hundFrame) ; 1.x = it; 

WinDestroyNsgQueue (hag) ; Epiline (hps, apth) i 

WinTerminate (hab) ; 





return 8 ; Epiiive (hps, aptlLineStart + TXTBOX_TOPRIGHT) ; 
} 1.y = cyClient ; 

Epiline (hps, &ptl) ; 

Gpifove (hps, aptiLineStart + TKTBOX_TOPLEFT) ; 

ULONG EXPENTRY ClientkndProc (HWND hund, USHORT nsg, ULONG ap1, pil.x= 8; 
; ULONG up2) Eptiine (hps, &ptl) ; 
static CHAR szText [] = "Graphics Programming Interface" ; iRestorePS (hps, -IL) ; IM Patch #/ 
static LONG ITextLength Besen stText Er R He “ 
static LONG alColorData[] = Hr BACKGROUND, Ban TE, T- WinEndPaint (hps) ; 
; break ; 
static POINTL En en Bir 
TextBox default: 
Baus SHORT exClient, eyClient ; return WinDefWindowProc (hund, usg, mpl, mp2) ; 
} 3 
im. Au return @L ; 
sIndex ; } 
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CACHEDPS. DEF: Die Moduldefinitionsdatei für CACHED- 
PS 











Listing 1: CHACHEDPS, CACHEDPS.C, CACHEDPS.DEF. 


MICROPS: Die Make-Datei für MICROPS 








A NICROPS Nnke-Datei 





aierops.ob) ; 





Kalt =2p microps.c 


microps.exe : microps.obj miı 
ink rer an] slibep 052, microps 








MICROPS.C: Der Quellcode von MICROPS 





Me 
NICROPS.C -- Beispiel für Micro-PS h 
D 











‚define INCL_WIN 
define INCL_GPI 


#include <0s2.h> 
ULONG EXPENTRY ClientWndProc (HWND, USHORT, ULONG, ULONG) ; 
HAB hab ; 
int sain (void) 
Me CHAR szClientClass [] = "MicroPS” ; 


HWND ae: hwndClient ; 
SC ause ; 


hab = KinInitialize (B) ; 
haq = WinCreatefisgQueue (hab, 8) ; 


WinRegisterClass (hab, szClientClass, ClientindProc, 
CS_SIZEREDRAN, 5 





hwndFrame = WinCreateStdWindow (HUND DESKTOP 
MS_VISIBLE | FS. en } PS_TITLEBAR 
I Fsst I FSMINNAX, 
szClientClass, mlerapsn, 
@L, NULL, 8, &hwndClient) ; 


while (WinGetiisg (hab, &qasg, NULL, 8, 8) 
WinDispate (hab, &gusg) ; ” 




















WinDestroykindov (hundFrame) ; 
WinDestroyfisgQueue I: 
inTerainate (hab) ; ni 


return 8 ; 
ULONG EXPENTRY ClientkindProc (HWND hund, USHORT zn ULONG a, 
ULONG ap: 
{ 
static CHAR szText [] = "Graphics Programming Interface” ; 


static HPS_hps ; 
static LONG sizeof szText - IL ; 
P AGB. WHITE, 
ITBLACK 


static LONG ee - (ar 

static POINTL et, en u, 7 
static SHORT cxClient, cyClient ; 

HDG hdc ; 

POINTL ptl; 

SHORT sIndex ; 

SIZEL sizl ; 

2 (usg) 


case LGEITE 
= HinöpenkiindowDC (hund) ; 





sizl.x =; 
sizl.cy=8; 


hps = GpiCreatePS (hab, hdc, &sizl, PU PELS | 
GR DENT | em ER 
GPIN_NORMAL | GPIATAS: 


LE MMoRee, dr (hps, LCOL_RESET, 
H AP sıcelorData)"; 


if 'extBox ITextLength, s: 
ha Oktiox COUNT, ıTertsen) ; 


GpiSetColor (hps, CLR RED) 
une (hps, Linehree, DOT) ; 


case WM SIZE: 
cxClient = LOUSHORT (mp2) ; 
cyClient = HIUSHÖRT (ap2) ; 


BEATS arE x = (cxClient - 
apt1TextBox [TXTBOX_BOTTONRIGHT].x - 
apt1TextBox [TXTBOX-BOTTONLEFT].x) / 2 ; 


ptlTextStart.y = (cyClient - 
apt1TextBox [TXTBOX_TOPLEFT 
apt\TextBox EherBoK-BorronleT. nr/2; 


for (sIndex = 8 ; sIndex < 4 ; 
aptiLineStart [sindex] = aptITextBox [sIndex] ; 


aptlLineStart [sIndex].x += ptlTextStart.x 
en [sIndex).y += ptlTextStart.y ; 


sIndex ++) 


break ; 

case WM PAINT: 
/®WinBeginpaint (hund, hps, NULL) ; #/ 
GpiErase (hps) ; 

iCharStringAt (I o tlTextStart, 

® al Tektle 'extLength, szText) ; 
Gpifove (hps, aptLineStart+TXTBOX_BOTTOMLEFT) ; 
ptl.x= : ; 


tl.y 
piilne (his, pt) ; 
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Br ed Nusfke „aptlLineStart+TXTBOX_| BOTTOMRIGHT) ; Bar BT ClientlindProc (HMND, USHORT, ULONG, ULONG) ; 
Line (hps, Apti) ; 

Move (I N Se + TXTBOX_TOPRIGHT) ; 
Ei: (hps, Bpti) ; 


int mein. (void) 
static CHAR szClientClass [] = "NormalPs" ; 
MO haq ; 
HUND  hundFrame, hundClient ; 


GpiNoye (hps, apkllinaStart + TATOR_TOFLEFT). ; ASC us ; 
“8; 
Briiine 0 (ps, pt) ; hab = WinInitialize (8) ; 


= WinCreatellsgQueue (hab, d; 
/®* WinEndPaint (hps) ; %/ 1 
WinRegisterClass (hab, szClientClass, ClientndProc, 
WinValidateRect (hund, NULL) ; /® Patch "/ ‚CS_SIZEREDRAN, 8, NULL) ; 


£ hwndFrane = WinCreateStälindov 
NE WISIBLE | PS SIZEBORDER | FS_TITLEBAR 


Se erestregs (pn) ; I FSCSYSHENU 1 FSZMINMAX, 





szClientClass, "Norsal-PS”, 
@L, NULL, 8, &hwndClient) ; 


default: 
return WinDefWindowProc (hund, „pl, up2) ; while (WinGe! (hab, NULL, 8, 8)) 
} WinDispat ee 
return BL ; 
} WinDestroyWindow (hundFrame) ; 


WinDestroyMsgQueue B 
Kinerainte (hab) =) 


Bere 








MICROPS. DEF: Die Moduldefinitionsdatei für MICROPS. 


ULONG EXPENTRY ClientlndProc (HWND hund, USHORT msg, et 

















ULONG mp2} 
fi 
static CHAR szText [) = "Graphics Programming Interface” ; 
static HS hps ; a 
Static LONG 1 "1; 
static LONG ITextLength = sizeof sText - IL; 
static LONG alColorData[] = {CLR_BACKGROUND, RB WHITE, 
GLRNEUTRAL, " RGBZBLACK ) ; 
static POINT. aptITentBox UIKTBOR OU; 
POINTL 1, ptlTextStart, aptiLineStart [4] ; 
SHORT Ertisbnt, eychient, Binder + B 
SIZEL Fr 
Listing 2: MICROPS, MICROPS.C, MICROPS.DEF, lee) 
a nöpenitindovDC (hund) 
NORMALPS: Die Make-Datei für NORMALPS E 
sizl.cx 
sizl.cy 
= @plGrentePS (ha, hc, Aslzl, PUPEIS.. | 
eg GPIF DEFAULT |'CPIT_NORNAL | 
GINCNORIAE. | GIKCSOCH » 


iCreai lorTablı ir RESET, 
ee nes, BL0 Al Blcolorata)'; 




















‚exe : # . 1QueryTextBox (hps, 1TextLength, szTe 
ana norsalps, De alien wi A elibep 02, normalps . (_COUNT, plıTention) ; 
Bagen (hps, DCTL ERASE, DCTL_ON) ; 
ingode (hps, DN_RETAIN) ; 
NORMALPS.C: Der Quellcode von NORMALPS 
case WM SIZE: 
exClient = (mp2) ; 
uns leer eyClient = 2 Hnushonr (ap2) ; 
NORMALPS.C -- Beispiel für normalen PS pilTextstart.x » (excitent - 
a el apt1TextBox [TXTBOX_BOTTOMRICHT].x - 
fextBox [TXTBOX_BOTTONLEFT. ; 
‚#define INCL_WIN aptITı [i 1.2) /2; 
‚#define INCL_GPI piiTentsart, 1,0 
 Fhersor. 
include <0s2.h> epkiTenttor entäox LTKTBOECBOTIDILERTI. „/2; 
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N PhnbeginPaint (und, hps, NULL) ; ®/ 


for (sIndex = 8 ; sIndex ++) 





aptlLineStart [sIndex] = BTRE [sIndex] ; 
aptilinestart [sIndex).x += ptlTextStart.x ; GpiDravChain (hps) ; 
aptiLineStart [sIndex].y += ptlTextStart.y ; 


‚/® WinEndPaint (hps) ; #/ 


GpiDeleteSeguent (hps, 1Segnentlane) ; Karen (md, NULL) ; Im Patch w/ 
’ 


GpiOpenSeguent (hps, 1Segnenthame) ; 
GpiSetColor (hps, CLR_RED) ; 


Gpi@arStringMe (ps, AptlTextstart, 
'extLength, E 


case BIETE: 1Segnentiae 
een rg Ara 
are es 


default: 
return WinDefWindowProc (hund, msg, mpl, mp2) ; 


aa 


GpiSetLineType (hps, LINETIPE_DOT) ; 
GpiNovelhps, + 
ptl.x= 8 

Esiifne (hps, Aptl) ; 


Move . Wir sorron 
= ve  BOrTOrRIGM) ; 
1.x = cxClient 


iLine (hps, pl); 
a (hps, aptlLineStart + 


TOPRIGHT) ; 
hülne (ps, dp Beh; 


Gpihove (hps, Kr Se 


I.x=8 





NORMALPS. DEF: Die Moduldefinitionsdatei für NORMAL- 











Listing 3: NORMALPS, NORMALPS.C, NORMALPS. DEF, 
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Koordination von Threads mit Semaphoren 


OS/2-Semaphore sind ein mächtiger Mecha- 
nismus, um mehrere gleichzeitig ausgeführte 
Threads zu koordinieren. Ein häufiger Anwen- 
dungsfall ist die Zugriffssteuerung auf Pro- 
grammteile und auf Ressourcen, die von diesen 
Teilen benötigt werden. Ein weiterer Anwen- 
dungsfall für Semaphore ist das Signalisieren 
eines Threads an einen anderen, wenn ein Ereig- 
nis stattgefunden hat wie zum Beispiel die Been- 
digung einer Ein-/Ausgabeoperation. OS/2- 
unterstützt beide Semaphor-Anwendungsfälle. 


Es gibt vier Arten von Semaphoren in OS/2: exklusive, 
nichtexklusive, RAM- und FSRam-(Fast-Save-RAM)-Sema- 
phore. FSRam-Semaphore sind neu seit der Version 1.1 von 
OSJ/2. Nichtexklusive System- und RAM-Semaphore kön- 
nen für die Zugriffssteuerung und das Signalisieren ver- 
wendet werden; exklusive und FSRam-Semaphore sind nur 
für die Zugriffssteuerung vorgeschen. FSRam-Semaphore 
sind mittelmäßig sicher, und ihre Geschwindigkeit ist ver- 
gleichbar mit der von RAM-Semaphoren. 

Systemsemaphore können von Threads verschiedener 
Prozesse, die keinen gemeinsamen Speicher besitzen, ver- 
wendet werden und sie bieten gegenüber den anderen bei- 
den einige Sicherheitsvorteile. Zukünftige Versionen von 
OS/2 werden weitere Schutzmechanismen und die Netz- 
werkunterstützung für Systemsemaphore bieten. 

Wenn der Zugriff auf wiederverwendbare Ressourcen 
wie eine Datei, eine Datenstruktur oder des Bildschirms 
geregelt werden muß, so ordnet man der Ressource ein 
Semaphor zu und erlaubt immer nur einen Semaphor-Besit- 
zer. Ein Thread erhält die Kontrolle über das Semaphor 
durch den Funktionsaufruf von DosSemRequeset oder 
DosFSRamRequest. Ist das Semaphor frei, erhält der Auf- 
rufer den Rückgabewert 0 und der Thread kontrolliert das 
Semaphor. Ist das Semaphor schon belegt, kehrt der Aufruf 
entweder sofort zurück (wenn der Timeout-Parameter 0 ist) 
bzw. wartet n Millisekunden (Timeout = n) oder wartet 
undefiniert (Timeout = 1). Man sagt, der Thread ist 
blockiert, wenn er auf den Abschluß einer Semaphor- 
anfrage wartet. Wenn der aufrufende Thread die Kontrolle 
über ein Semaphor erhält, bevor die Timeout-Periode vor- 
über ist, erhält er sofort einen Rückgabewert von 0. Ande- 
renfalls wartet er, bis die Timeout-Periode vorüber ist, und 
erhält einen Wert ungleich 0. Ein Thread gibt die Kontrolle 
über ein Semaphor mit den Aufrufen DosSemClear oder 
DosFSRamSenClear ab. 

FSRam- und exklusive Systemsemaphore (Systemsema- 
phore, bei denen die NoExclusive-Option beim Erzeugen 
des Semaphors mit DosCreateSem nicht angegeben 
wurde) eignen sich gut für die Zugriffststeuerung. RAM- 
Semaphore und nichtexklusive Systemsemaphore erlauben 
auch die Zugriffssteuerung, Sie sollten aber bei der Ver- 
wendung einige Regeln befolgen. 
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Somaphortyp Venundung Schutz Leistung 
Exklusives | Exklusiver | Zwischen Thrands 
System Zugriff in verschiedenen 
Prozessen aan 
Einige Sicherheit 
wird von 05/2 ig 
geährleistet 
wicht- Exklusiver 
wclusives | Zugriff Zwischen Thrende 
System in verschiedenen 
Prozessen 
Signalisieren 
z Zwischen Thrends | Kinimaler 
Exklusiver | eines Schutz, 
Zugriff Prozesses nicht 
u vom Sehr 
Zwischen Threads, Betriebs- groß 
Sigualisieren | in selben oder system 
einen underen Prozeß | vermitet. 
FSBam Exklusiver | Zwischen Threads Etwas Schutz, 
fiagtsufe | Zuritt in verschiedenen teilweise Groß 
) Prozessen von 08/2 
veraltet 























Tabelle 1: Übersicht der Semaphortypen. 


Ganz gleich, ob Semaphore für die Zugriffssteuerung 
oder das Signalisieren verwendet werden, sie können die 
Unannehmlichkeiten eines Deadlocks, der Verletzung der 
Zugriffssteuerung, oder eines Prozeßabbruchs hervorrufen, 
während sie die Kontrolle über Ressourcen besitzen. Durch 
die sorgfältige Analyse der Anwendung, der Kenntnisse der 
OS/2-Semaphor-Funktionen und durch Befolgen einiger 
Regeln können solche Probleme verhindert werden. 


Semaphor-Typen 


Bevor Sie ein Programm mit Semaphoren schreiben, sollten 
Sie sich zwei Fragen beantworten, Dient das Semaphor der 
Zugriffssteuerung oder dem Signalisieren? Ist es für ver- 
schiedene Threads des gleichen oder verschiedener Pro- 
zesse bestimmt? Die Antwort auf diese beiden Fragen klä- 
ren, welche Art von Semaphor Sie benützen müssen, und 
mit welchen Systemfunktionen sie angesprochen werden. 
Für die Zugriffssteuerung und die Synchronisation ver- 
schiedener Threads eines Prozesses sollten Sie RAM-Sema- 
phore verwenden, für die Zugriffssteuerung von Threads 
verschiedener Prozesse FSRam-Semaphore und für das 
Signalisieren zwischen Threads verschiedener Prozesse die 
nichtexklusiven Systemsemaphore oder RAM-Semaphore. 

Alle OS/2-Semaphor-Operationen basieren auf einer 
Semaphor-Handle, die 32 Bit groß ist. Im Falle des RAM- 
und des FSRam-Semaphors ist die Handle die Adresse der 
Datenstruktur. Im Falle des Systemsemaphors ist es der 
Wert, der von den Funktionsaufrufen DosCreateSem und 
DosOpenSem zurückgegeben wird. 





[02772 





if( rc=DosCreateSen( NoExclusive, &sysSen, &senNane)) 
if( rc == ERROR_ALREADY_EXISTS) 
DosOpenSem("&sysSen, &senName) ; 
<...Fehler...> 
©. .Vervendung des Senaphors...> 


DosCloseSen( sysSen) ; 








Listing 1: Die Verwendung von Systemsemaphoren. 


RAM-Semaphore 


RAM-Semaphore dienen hauptsächlich zur Koordination 
der Threads eines Prozesses. Sie sind schnell, da sie die 
einfache Datenstruktur eines Doppelworts haben, und 
wenig Verwaltung oder Schutz durch OS/2 erhalten. 

RAM-Semaphore können zwischen verschiedenen Pro- 
zessen verwendet werden, die gemeinsamen Speicher 
benutzen, der durch DosAllocShrSeg angefordert wurde. 
RAM-Semaphore können aber nicht für die Zugriffssteue- 
rung zwischen Prozessen verwendet werden, da OS/2 ein 
RAM-Semaphor nicht freigibt, wenn der Besitzer, der es 
kontrolliert hat, endet. Sie eignen sich gut für die 
Zugriffssteuerung zwischen Threads desselben Prozesses 
und können zum Signalisieren innerhalb oder zwischen 
Prozessen dienen. 

Ein RAM-Semaphor ist ein Doppelwort-Speicherplatz, 
dessen Inhalt mit 0 (zurückgesetzt/nicht kontrolliert) initia- 
lisiert sein muß, bevor es als Semaphor verwendet wird. Es 
sollten anschließend folgende Funktionen benutzt werden: 
DosSemClear, DosSemRequest, DosSemSet, DosSem- 
SetWait, DosSemWait oder DosMuxSemWait. 


Systemsemaphore 


Systemsemaphore sind die flexibelsten, sichersten und am 
leichtesten zu benutzenden Semaphore, aber ein Problem 
bei der Benutzung ist der Geschwindigkeitsnachteil. Sie 
brauchen keinen gemeinsamen Speicher, und ihr Besitz 
endet, wenn ihr Besitzer beendet wird. Deshalb eignen sie 
sich gut für die Zugriffssteuerung zwischen Prozessen. 

Jeder Prozeß, der ein Systemsemaphor benötigt, muß 
von OS/2 mit den Funktionen DosCreateSem oder Dos- 
OpenSem eine Handle anfordern. Der Prozeß liefert einen 
mit 0 abgeschlossenen Semaphornamen, im gleichen For- 
mat wie einen Dateinamen einer Datei im Unterverzeichnis 
\SEM\, zum Beispiel \SEM\RESOURCE.LCK. OS/2 gibt 
dann die Handle für den weiteren Zugriff zurück. Der Pro- 
zeß gibt auch an, ob nichtbesitzende Prozesse den Zustand 
des Semaphors ändern können. Systemsemaphore werden 
in der Regel zum Signalisieren nicht exklusiv und für die 
Zugriffssteuerung exklusiv erzeugt. 


long resourceSen = B; 


Tea 


DosSenRequest( AresourceSen, -1L); 
&... lesen/ändern der Ressource ...> 
DosSenClear( &resourceSen); 


} 
Fa ) 


DosSeaRequest( &resourceen, -IL); 
<... schreiben/ändern der Ressource... 
DosSenClear( AresourceSen); 











Listing 2: Zwei Threads haben nacheinander exklusiven Zu- 
griff auf eine Ressource. 


DosCreateSem wird verwendet, wenn das Semaphor 
noch nicht existiert (existiert es bereits, erhält der Aufrufer 
einen Fehlercode), und das Semaphor wird als nicht kon- 
trolliert initialisiert. DosOpenSem wird verwendet, wenn ein 
anderer Prozeß das Semaphor erzeugt hat; falls es nicht exi- 
stiert, wird ein Fehlercode zurückgegeben. Wenn in Ihrer 
Anwendung ein Prozeß ganz bestimmt zuerst läuft, kann er 
DosCreateSem verwenden. Spätere Prozesse können dann 
DosOpenSem aufrufen. Ist die Reihenfolge der Prozesse 
unbekannt, kann jeder DosCreateSem aufrufen, und falls 
der Aufruf einen Fehler zurückmeldet, weil das Semaphor 
bereits existiert, DosOpenSen. 

Wenn ein Prozeß ein Systemsemaphor nicht mehr 
benötigt, sollte er DosCloseSem aufrufen. Das System- 
semaphor wird gelöscht, wenn alle Prozesse, die das 
Semaphor benutzen, DosCloseSem aufgerufen haben. 
Wird ein Prozeß mit offenem Systemsemaphor beendet, 
dann schließt das System dieses (Listing 1). 

Ein Thread sollte normalerweise kein Semaphor anfor- 
dern, das er bereits kontrolliert. Dies würde ihn blockieren, 
bis er selbst das Semaphor freigibt, was einem Deadlock 
entspricht. 

Ein Systemsemaphor, das mit der exklusiven Option 
erzeugt wurde, blockiert einen Thread nicht, wenn er einen 
DosSemRequest-Funktionsaufruf durchführt, während er 
das Semaphor kontrolliert. Statt dessen wird der Nutzungs- 
zähler des Semaphors erhöht. Bei jedem Aufruf der Funk- 
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tion DosSemClear wird der Nutzungszähler vermindert, 
und wenn er 0 ist, wird das Semaphor freigegeben. Beach- 
ten Sie, daß ein solches Semaphor nicht einem klassischen 
Semaphor entspricht, das später in diesem Artikel noch 
beschrieben wird. Will ein anderer Thread ein exklusiv ver- 
gebenes Semaphor mit DosSemRequest anspricht, wird er 
blockiert und muß warten bis der Nutzungszähler 0 ist. 

Nichtexklusive Systemsemaphore verhalten sich wie 
RAM-Semaphore, wenn Sie mit DosSemClear, DosSem- 
Request, DosSemSet, DosSemWait oder DosMuxSem- 
Wait angesprochen werden. 


FSRam-Semaphore 


FSRam-Semaphore erlauben die Zugriffsteuerung zwischen 
Prozessen und bieten fast die Geschwindigkeit von RAM- 
Semaphoren in Kombination mit der Sicherheit von 
Systemsemaphoren. Sie benutzen eine einfache Daten- 
struktur und benötigen geringen Systemaufwand. Ihre 
Ausführungsgeschwindigkeit ist deshalb sehr gut. Da sie 
Daten zur Verwaltung der Semaphorbesitzer führen, erlau- 
ben FSRam-Semaphore der Funktion DosExitList das 
Freigeben einer kontrollierten Ressource, wenn der Prozeß 
endet. 

Ebenso wie die exklusiven Systemsemaphore erlauben 
FSRam-Semaphore rekursive DosFSRamSemRequest-Zu- 
griffe durch das Hochzählen eines Nutzungszählers, und sie 
unterstützen DosFSRamSemClear, indem sie den Nut- 
zungszähler vermindern. Wird der Nutzungszähler 0, ist das 
Semaphor frei. (Beachten Sie aber bitte wieder, daß ein 
Semaphor sich von einem klassischen Zählsemaphor unter- 
scheidet.) DosFSRamSemRequest und DosFSRamSenm- 
Clear sind die einzigen in OS/2 verfügbaren Funktionen 
für FSRam-Semaphore. 

FSRam-Semaphore befinden sich im gemeinsamen 
Speicher der kooperierenden Prozesse und haben ein Län- 
genfeld von 12; alle anderen Felder sind vor dem Gebrauch 
auf 0 initialisiert. 


Zugriffssteuerung 


In 0S/2 können Semaphore gewährleisten, daß nur ein 
Thread zu einer Zeit Zugriff zu einer geschützten Res- 
source hat. Dies wird durch die Zuordnung eines 
Semaphors zu der geschützten Ressource erreicht und mit 
den Programmierkonventionen erreicht, daß jedes Pro- 
grammteil, das diese geschützte Ressource benötigt, vorher 
einen DosSemRequest-Funktionsaufruf (oder DosFSRam- 
SemRequest) und nachher einen DosSemClear-Funk- 
tionsaufruf (oder DosFSRamSemClear) durchführen muß. 
Es ist wichtig, daß jeder beteiligte Thread sich an dieses 
Schema hält, ansonsten treten zeitabhängige Fehler auf. 

Der Thread, dessen Semaphoranforderung ohne Feh- 
lermeldung erledigt wird, kontrolliert das Semaphor und 
alle anderen Threads, die einen ähnlichen Aufruf durchfüh- 
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ren, sind blockiert. Dies ermöglicht dem kontrollierenden 
Thread den exklusiven Zugriff zu dem Programmteil, der 
die geschützte Ressource verwendet. Benötigt der Thread 
die geschützte Ressource nicht mehr, löscht er das 
Semaphor und gibt es dadurch ab. Ist ein anderer Thread 
wegen der Anforderung des inzwischen wieder verfügbaren 
Semaphors blockiert, kann er jetzt fortfahren und auf die 
geschützte Ressource zugreifen. 

Stellen Sie sich zum Beispiel zwei Threads vor, die ein 
Semaphor benutzen, um die Zugriffssteuerung auf eine 
Ressource zu regeln. Sie verwenden vielleicht einen Pro- 
grammteil wie im Listing 2, wo die 1 signalisiert, daß der 
Thread undefiniert lange wartet, bis das gewünschte 
Semaphor verfügbar ist. 

Die vorher beschriebene Programmierkonvention sollte 
strikt eingehalten werden, außer wenn sie für eine spezielle 
Anwendung nicht benötigt wird. Sogar eine nur leichte 
Abwandlung kann zu einem Zugriffsfehler, Deadlock oder 
beidem führen. 

Ein FSRam-Semaphor kann für die Zugriffssteuerung 
zwischen Threads verschiedener Prozesse sicher benutzt 
werden, wenn jeder Prozeß ein Wiederherstellen im Falle 
der Beendigung vorsicht, während er das Semaphor noch 
kontrolliert. Vor der Beendigung sollte jeder Prozeß eine 
ExitList-Routine ausführen, um die Integrität der 
geschützten Ressourcen durch den Funktionsaufruf Dos- 
ExitList zu gewährleisten. Bei der Beendigung des Pro- 
zesses wird die ExitList-Routine aufgerufen. Diese sollte 
zuerst DosFSRamSemRequest aufrufen, um die Kontrolle 
über das Semaphor zu erhalten, dann die Ressource in 
Ordnung bringen und schließlich DosFSRamSemClear auf- 
rufen, um die Ressourcen für die Benutzung der anderen 
Prozesse freizugeben. 

Wird das FSRam-Semaphor von einem Thread des 
beendenden Prozesses kontrolliert, wenn DosFSRamSem- 
Request während der ExitList-Routine ausgeführt wird, 
wird die Thread-ID des kontrollierenden Threads zur 
momentanen Thread-ID und der Nutzungszähler auf 1 
gesetzt. Dies erlaubt der ExitList-Routine die Ressource in 
einen sicheren Zustand zu versetzen und sie dann mit 
DosFSRamSenClear freizugeben (Listing 3). 

RAM-Semaphore sollten nur für die Zugriffssteuerung 
von Threads desselben Prozesses benutzt werden. In diesem 
Fall sind sie effizient (da es wenig Systemoverhead gibt), 
leicht verwendbar (da Threads sich Speicher teilen) und 
sicher (da der Prozeß nur endet, wenn alle seine Threads 
enden). 

Es ist möglich, ein nichtexklusives Systemsemaphor für 
die Zugriffssteuerung zu benutzen, aber alle Threads, die 
das Semaphor benutzen, müssen sich an die Programmier- 
konventionen für den aufeinanderfolgenden Zugriff halten. 
Nichtexklusive RAM-Semaphore verhalten sich im allge- 
meinen ähnlich wie RAM-Semaphore. Wenn aber der 
Besitzer stirbt, während er es kontrolliert, erhält der näch- 
ste Thread beim Aufruf von DosSemRequest das Sema- 











main) 
t 


DosExitList( 1, ACleanup); /® Zur Exit-Liste hinzufügen®/ 
} 
Hanel) 

int DosFSRanSenRequest( &sem, BL) != ERR_TIMEOUT) 


<... in einen sicheren Zustand überführen ...> 
‚lear( &sen); 


} 
DosExitList( 3, 8); /= nächste ExitList-Routine aufrufen #/ 











Listing 3: Überführen einer Ressource in einen sicheren 
Zustand. 


phor und einen Fehlercode. Der neue Besitzer, ein richtiger 
Thread oder eine ExitList-Routine, kann die Ressource 
in Ordnung bringen und DosSemClear aufrufen. 

Exklusive Systemsemaphore können zur sicheren Zu- 
griffssteuerung zwischen verschiedenen Prozessen benutzt 
werden, da die Datenstruktur des Systemsemaphors eine ID 
des kontrollierenden Threads enthält und jeder Versuch 
eines Threads, den Status eines exklusiven Systemsema- 
phors zu ändern, die von einem ander Thread kontrolliert 
wird, veranlaßt eine Blockierung des Threads oder die 
Rückgabe eines Fehlercodes. 

Wenn ein Thread im Besitz der Kontrolle eines System- 
semaphors ist und entweder er selbst endet, oder sein Pro- 
zeß beendet wird, wird in der Struktur des Semaphors ein 
Flag gesetzt. Der nächste Thread, der das Semaphor bei 
einem Funktionsaufruf von DosSemRequest erhält, 
bekommt den Fehlerhinweis, daß der Besitzer des 
Semaphors beendet ist und kann passende Wiederherstel- 
lungsmaßnahmen durchführen. Ein nachfolgender Aufruf 
von DosSemClear gibt das Semaphor frei und löscht das 
Fehlerflag. 

ExitList für die Bearbeitung von Systemsemaphore, 
die für die Zugriffssteuerung benutzt werden, gleicht stark 
der ExitList-Bearbeitung von FSRam-Semaphoren. 


Signale 


RAM- oder nichtexklusive Systemsemaphore erlauben das 
Erkennen eines Ereignisses in anderen Threads. Nehmen 
Sie zum Beispiel den Fall, daß der Programmteil Fi in 
Thread 1 vor dem Programmteil F2 in Thread 2 ausgeführt 
werden muß und das Systemsemaphor mit der Handle 
sigSem mit der Option »nichtexklusiv« erzeugt wurde. Das 
Programm könnte aussehen wie das in Listing 4. 


DosSenSet( sigSen); 


amat 0 


ti 
DosSenClear( sigSem); 


Miranda ) 


Dossenkatt( sigsen, -1L); 








El 





Listing 4: Signale zwischen Threads. 


Im ungünstigsten Fall könnte Thread 2 den Aufruf von 
DosSemWait ausführen, bevor Thread 1 die Ausführung 
von Fi beendet, wodurch er blockiert wird. Wenn der 
Thread 1 die Bearbeitung von F1 beendet, löscht er 
sigSem und der Thread 2 fährt mit der Ausführung von F2 
fort. 

Die Semaphorfunktionen DosSemSet, DosSemClear, 
DosSemWait und DosMuxSemWait dienen der Bearbei- 
tung von Signalen. DosSemSet setzt das Semaphor, Dos- 
SemClear löscht es. DosSemWait blockiert den Thread, 
bis das Semaphor gelöscht ist oder bis ein optionales 
Timeout-Intervall verstrichen ist. DosSemSetWait ist eine 
untrennbare Kombination von DosSemSet gefolgt von 
DosSemWait. DosMuxSemWait blockiert den Thread, bis 
ein Semaphor aus einer Liste gelöscht oder bis ein Timeout- 
Intervall verstrichen ist. 

Sie sollten die Signalaufrufe nicht mit exklusiven 
Systemsemaphoren durchführen. Nehmen Sie zum Beispiel 
einen Thread, der DosSemSetWait benutzt. Wird das 
exklusive Systemsemaphor bereits kontrolliert, wird ein 
Fehler zurückgegeben. Anderenfalls setzt der Thread das 
Semaphor und wartet, bis es gelöscht wird. Das passiert 
aber nicht, da kein anderer Thread es löschen kann. 

Listing 5 zeigt ein Beispiel von DosSemSetWait, ähn- 
lich dem oben erwähnten mit DosSemWait, aber diesmal in 
einer Endlosschleife. Der Programmteil F2 kann nur einmal 
für jede Bearbeitung von F1 ausgeführt werden. 

Listing 6 zeigt die Verwendung von DosMuxSemWait. 
In diesem Fall blockiert Thread 4 bis entweder Thread 1, 
oder Thread 2 oder Thread 3 ihre Semaphore löschen. 
Thread 4 fährt fort und führt die für den signalisierenden 
Thread passende Aktion aus. 


Juli/August 1988 Microsoft System Journal 43 








threadi() 
{ . 
untecı) 


Fl 
DossenClear( sigsen) ; 


} 
Hirte ’ 


inte) 
DossenSethait( segsen, -IL) ; 











Listing 5: Die Verwendung von DosSemSetWait. 


Ebenso wie bei der Zugriffsteuerung ist bei der Ver- 
wendung von Semaphoren für die Signalbearbeitung eine 
gründliche Analyse notwendig, um Deadlocks oder Syn- 
chronisationsfehler zu vermeiden. 


Ringpuffer 


stellen Sie sich vor, zwei Threads eines Prozesses kommu- 
nizieren über einen Ringpuffer. Thread 1 schreibt in den 
Puffer, Thread 2 liest aus dem Puffer. Der Puffer hat eine 
feste Länge, bufSize, und Zeiger auf den neuesten (head) 
und den ältesten (tail) Datensatz. Der Puffer ist in dem 
Sinne ringförmig, daß jeder Thread nach dem Zugriff auf 
die Position bufSize - 1 auf Position 0 zugreift. Der 
Puffer ist leer, wenn head == tail, und er ist voll, wenn 
tail == head + 1 (mod bufSize). 

Stellen Sie sich weiter vor, daß mutexSem, emptySem 
und fullSem RAM-Semaphore sind, und daß die Befehle 
DosSemClear (&mutexSen); 
DosSemSet(&emptySem); 

DosSemClear (&fullSen); 
head = tail = 8; 

ausgeführt werden, bevor die Threads starten. Dann 
würden die beiden Threads so aussehen wie in Listing 7. 

Die geschützte Ressource ist in diesem Fall der Puffer, 
nebst seinen Variablen (head, tail, emptySem und 
fullSem). Jeder Thread greift auf die geschützten Res- 
sourcen zwischen den Funktionsaufrufen DosSemRequest 
und DosSemClear für das ausschließlich einem vorbehal- 
tene Semaphor mutexSem zu. Die Zugriffe erfolgen nach- 
einander und es entsteht keine Konkurrenzsituation. 
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struct { 
int nunSen; 
int resl; 
unsigned long sentandle1; 
int res2; 
unsigned long senhandle2; 
erst: 
long st e3; 
male: 
int muxIndex; 


Fk 0 


Fl 
DosSenClear( sigSen!) ; 


ee) 


F2 
DosSemClear( sigSen2) ; 


} 
en ) 


F3 
DosSeaClear( sigSen3) ; 


Fk 0 


muxSenList.nunSen = 3 ; 
auxSenlist.res! = 8; 
nuxSenList.seaHandlei = sigSen! ; 
muxSenlist.res2 = 8 ; 
auxSenlist.seaHandle2 = sigSen2 ; 
muxSenList.res3 = 8 ; 
auxSenList.semHandle3 = sigSen3 ; 


DosMuxSemhait( &muxIndex, &muxSenList, -IL) ; 
switch( muxIndex) { 

case 1: 

/#* Antvort auf FI #/ 

case 2: 

/%* Antwort auf F2 #/ 

case 3: 

/# Antwort auf F3 ®/ 

i) 











Listing 6: Die Verwendung von DosMuxSemWait. 
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aufweist, besteht seitens des kontoführenden 
eihstiukeme Verpflichtung zur Einlösung. 
Datum/Unterschrift 
Garantie 


Mir ist bekannt, daß ich diese Bestellung innerhalb 
einer Woche bei der Bestelladresse widerrufen kann. 
Zur Wahrung der Frist gen Ku die ERBEANGE Ab- 
sendung meines Widerrufsschreibens. 


Ich bestätige dies durch meine zweite Unterschrift. 





Datum/Unterschrift 


Garantie 

Mir ist bekannt, daß ich diese Bestellung inner- 

halb einer Woche bei der Bestelladresse wider- 

rufen kann, Zur Wahrung der Frist genügt die 

eg Absendung meines Widerrufs- 
eiben: 


Ich bestätige dies durch meine zweite Unter- 
schrift. 


Datum/Unterschrift 





Antwort 
schury praxisformulare GmbH 
Bereich Publikationen 
Postfach 270 
D-8200 Rosenheim 
Bitte mit 
wre 
freimachen 
Antwort 
schury praxisformulare GmbH 
Bereich Publikationen 
Postfach 270 
D-8200 Rosenheim 
Bitte mit 
Pig 
freimachen 
Antwort 
schury praxisformulare GmbH 
Bereich Publikationen 
Postfach 270 
D-8200 Rosenheim 
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use 0) 


<... Datensatz c holen .. 
DosSenhait( &fullSen, ij ; 


DosSemRequest( &nutexSen, Su 
'* c im Puffer ablegen */ 


Buffer... ‚head -c 
'head++ r Pufferzeiger erhöhen */ 
head PR bufsize Zurück zum Start */ 
1f(hendertait)I1((ta11-»9)&4(headenbufstzer -1))) 
DosSenSet( &fullSen); /* setzen wenn voll */ 


DosSenClear( tySem); /# nicht leer */ 
DosSenClear( ‚exSen); 
} 


eat ) 


DosSemkait( &emptySem, -IL); 


DosSenRequest( AmutexSen, -1L); 
ce» nee: tail; /# c vom Puffer holen */ 
ta! In Pufferende erhöhen #/ 
ak bufSize; 7" Zum Beginn ®/ 
1f( head«=tail) 

DosSenset( en: 
DosSenClear( &full. 
DosSenClear( &nutexse: 


&... e benützen ...> 


/# setzen wenn leer ®/ 
/* nicht voll #/ 














Listing 7: Beispiel für einen Ringpuffer. 


Vor dem Start der Threads ist die geschützte Ressource 
in einem gesicherten Zustand: head == tail, emptySem 
ist gesetzt und fullSem ist gelöscht. Jeder Thread beein- 
flußt den Zustand der geschützten Ressource so, daß wenn 
er vor der kritischen Sektion in Ordnung war, er es auch 
nach dem Verlassen ist. Wenn also Thread 1 einen Daten- 
satz in den Puffer einfügt, der den letzten freien Platz 
belegt, dann setzt er das Semaphor fullSem. Thread 1 
löscht immer das Semaphor emptySem, da er immer einen 
Datensatz in den Puffer einfügt. Ebenso setzt Thread 2 das 
Semaphor emptySem, wenn er den letzten Datensatz aus 
dem Puffer nimmt und löscht immer das Semaphor full- 
Sem, 

Ist der Puffer voll, setzt Thread 1 fullSem und 
blockiert bei fullSem. In diesem Fall wird emptySem 
nicht gesetzt und da Thread 1 außerhalb des kritischen 
Teiles blockiert, kann Thread 2 den kritischen Teil betreten, 
einen Eintrag aus dem Puffer entnehmen, ful1Sem löschen 
und damit dem Thread 1 die weitere Bearbeitung ermögli- 
chen. 


A 
. warten bis classicOountSen > 8 ...> 
classicCountSea--; 
vo 
classicCountSen++; 











Listing 8: Klassisches Zählsemaphor. 


Ist der Puffer leer, setzt Thread 2 emptySem und 
blockiert bei enptySem. Da fullSem nicht gesetzt ist, und 
Thread 2 außerhalb des kritischen Teiles blockiert, kann 
Thread 1 den kritischen Teil bearbeiten, einen Eintrag in 
den Puffer einfügen, emptySem löschen und dem Thread 2 
die weitere Bearbeitung ermöglichen. 


Die Simulation eines klassischen Semaphors 


Klassische Semaphore können leicht mit den Möglichkeiten 
nachgebildet werden, die die OS/2-Semaphore bieten. 
ClassicCountSem ist eine Integervariable, die abgesehen 
von der Initialsierung nur mit den beiden elementaren Ope- 
rationen P und V angesprochen werden kann (Listing 8). 

Zur Simulation von classicCountSem und der ent- 
sprechenden Operationen P und V verwenden Sie die OS/2- 
Semaphore countSem zum Signalisieren und mutexSem 
zur Zugriffssteuerung, die beide anfänglich gelöscht sind, 
und die Integer-Variable count, die anfänglich nicht nega- 
tiv ist (Listing 9). 

Alle Programmteile der Operationen P und V, die 
count und countSem ändern, liegen in sich gegenseitig 
ausschließenden Bereichen, die durch Aufrufe von mutex- 
Sem eingeschlossen werden, was das Analysieren der Rou- 
tinen erleichtert. 

Diese Routinen würden auch korrekt arbeiten, wenn die 
Referenzen auf countSem entfernt würden, aber P würde 
viel Zeit verbrauchen, um Bedingungen abzuprüfen, die 
nicht erfüllt sind. Das Warten (DosSemWait) auf count- 
Sem verhindert unnütze Aktivitäten, erlaubt aber auch P 
weiterzumachen, wenn eine Chance zum Beenden besteht. 
P blockiert nur auf countSem, wenn count 0 ist. Wenn V 
ausgeführt wird, wird count erhöht und countSem ge- 
löscht, was P erlaubt, weiterzumachen, bis count erneut 0 
ist. Deshalb haben alle wartenden Ps die Gelegenheit, die 
von V »erzeugten« Einheiten aufzubrauchen. 


Verwaltung 


Das Zeitverhalten und die Synchronisierung der Threads 
mit Semaphoren wird durch die Aktivitäten der anderen 
Threads im System, zum Beispiel Priorität und Position in 
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der Liste der blockierten Threads, beeinflußt. Wenn meh- 
rere Threads auf ein Semaphor warten, sollte Ihre Anwen- 
dung nicht glauben, die nächste zu sein, die ausgeführt wird, 
da Faktoren außerhalb Ihrer Kontrolle den Verwalter in 
seiner Entscheidung beeinflussen können. 

DosSemWait, DosSemSetWait und DosSemRequest 
sind pegelgesteuert. Das bedeutet zum Beispiel, daß ein bei 
diesen Aufrufen blockierter Thread nur wieder ausgeführt 
wird, wenn das blockierende Semaphor gelöscht bleibt, bis 
der blockierte Thread wirklich starten kann. Setzt ein ande- 
rer Thread im Computer in der Zwischenzeit das Semaphor 
wieder, bleibt der blockierte Thread blockiert. Bleibt das 
Semaphor gelöscht, bis der blockierte Thread wieder an der 
Reihe ist und starten kann, dann kehrt der Funktionsaufruf 
zurück, und der ehemals blockierte Thread startet wieder. 

DosMuxSemWait andererseits ist flankengesteuert. Das 
bedeutet, daß ein beim Aufruf von DosMuxSemWait 
blockierter Thread zurückkehrt, wenn eines der Semaphore 
in der Liste gelöscht wird, sogar dann, wenn das Semaphor 
von einem anderen Thread wieder gesetzt wird, bevor der 
blockierte Thread erneut starten kann. 


Zusammenfassung 


Semaphore in OS/2 können für die Zugriffsteuerung auf 
geschützte Ressourcen verwendet werden, indem das 
Semaphor der Ressource zugeordnet wird und die OS/2- 
Funktionsaufrufe so eingesetzt werden, daß gewährleistet 
ist, daß das Semaphor zu einer Zeit nur einen Besitzer hat. 









Ein Werkzeug setzt sich durch: 


für viele Programmiersprachen 


Vorteile: ® lieferbare Programmierschnittstellen für Turbo C, 


MS-C, Lattice €, Turbo-Pascal (auch V.4.0), 
MS-Pascal, MS-Fortran, Modula 2 und Cobol 


© mit interaktivem Maskeneditor 
(what you see is what you get) 


Editieren (ändern) bestehender Masken möglich 
mit Maskenlaufzeitsystem zur Bildschirm- und Tastatursteuerung 
leistungsstarke Debug-Möglichkeiten 

@  selbstablaufende Demo des Anwenderprogrammes möglich 





Mit Handbuch auf 3 Disketten zum Selberausdrucken. 


TURCK-MESSY * das PROFI-Maskenentwicklungssystem 


Eine komplett lauffähige Demo-Version (ohne Programmierschnittstelle) erhalten Sie bei Zahlungseingang von DM 17,50 auf unserem Postgirokonto München 
332533-807 (BLZ 70010080). TURCK-MESSY * kostet DM 445,- (DM 390,- o. MwSt.); jede Programmierschnittstelle DM 320,- (DM 280,- o. MwSt.) 








PO) 
int blocked=1; 
while( blocked == 1) 
! DosSemkait( &countSea); /* warten bis vielleicht ok ®/ 
et AnutexSen, a /® ausschlieplich #/ 


{count = «nicht bereit gesetzt ®/ 
5 Dessen keduntsen); ee eben “ 
else 

count-- /" Zähler erniedrigen 


/* Schleifenende setzen */ 
/® ausschlieslich Y 


} blocke: 
Keezesieert änutexSen); 





vo 

t 
sven &nutexSem, -1L); /* ausschlieplich A 
count++; /* Zähler erhöhen A 
DosSenClear( &countSem); In kartende erwecken %/ 
DosSenClear( &mutexSen); /% ausschließlich “ 











Listing 9: Simulation eines klassischen Semaphors unter 


OS/2. 


Semaphore gestatten es einem Thread auch, einem anderen 
Thread zu signalisieren, daß ein Ereignis aufgetreten ist. 
Indem Sie die jeweilige Anwendung analysieren, können Sie 
das passende Semaphor und die benötigten OS/2-Funkti- 
onsaufrufe herausfinden. Kevin Rudell 





An 


© zahlreiche Plausibilitätsprüfungen (z.B. Wertebereiche) innerhalb 
des Maskenlaufzeitsystems möglich (ohne Belastung des 
Anwenderprogrammes) 


® Formeln zwischen Feldern einer Maske möglich (automatisches Rechnen) 
® biszu 8 Windows möglich 

© Rapid-Prototyping ohne Programmierkenntnisse möglich 

. 


mit Installationsprogramm für die verschiedenen Rechnertypen 
(auch nicht »KOMPATIBLE«) 


© siche PC Magazin Nr. 6/1987 
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Buchbesprechungen 


Wichtige englischsprachige Neuerscheinungen für Programmierer: 
Programmierwissen im Überfluß 


Bei der Programmierung von Personalcomputern ist es für 
eine schnelle Benutzerschnittstelle fast unumgänglich, 
direkt auf den Bildschirmspeicher zuzugreifen, denn bei der 
Programmierung von Bildschirmzugriffen über die BIOS- 
Routinen wird jedes interaktive Programm unnötig lang- 
sam. Wenn man ein solches Programm für nur einen Bild- 
schirmadapter schreibt, ist noch relativ gut an die benötig- 
ten Informationen heranzukommen, doch sobald man sein 
Programm zu einer universellen Version machen möchte, 
die auf allen gängigen Bildschirmadaptern läuft, steht man 
im Dunkeln. Die benötigten Informationen über alle Adap- 
ter sind fast unmöglich zu beschaffen. Endlich gibt es nun 
mit »Video Systems« von Richard Wilton ein Werk, das alle 
Informationen über folgende Bildschirmadapter enthält: 


= MDA (Monochrome Device Adapter) 

= CGA (Color Graphics Adapter) 

= HGC (Hercules Graphics Card & Plus) und Varianten 
(z.B. ColorCard und InColor Card) 

= EGA (Enhanced Graphics Adapter alias HR-Adapter) 

= VGA (Video Graphics Array) 

= MCGA (Multi-Color Graphics Array) 


Doch werden die benötigten Informationen nicht nur 
aufgelistet, sondern für alle häufig benötigten Zugriffe auch 
fertige Routinen in Assembler und C vorgestellt, die von C- 
oder Assemblerprogrammen aufgerufen werden können. 
Eine Übersicht über die Kapitel des Buches, zeigt sehr 
deutlich, wie umfassend das Thema behandelt wird. 


= Bildschirmhard- und -firmware bei Personalcomputern 
(Vorstellung der verschiedenen Adapter und des ROM- 
BIOS) 

w Programmierung der Hardware (Funktionelle Bestand- 
teile der Bildschirmadapter, Refreshzyklen, Program- 
mierung des CRT-Controllers, CRTC-Berechnungen, 
Statusregister, Bildschirmmodi) 

= Textmodi (Attribute, Randfarben, Bildschirmflimmern, 
Puffer, Cursorsteuerung) 

= Grafikmodi (Pixeladressierung, Attribute von Pixeln) 

= Pixelprogrammierung (Bit-Plane-Programmierung, Pixel 
lesen und setzen) 

= Linien (Linien effektiv zeichnen, Optimierungen, Clip- 
Ping) 

= Kreise und Ellipsen (Algorithmen zum Zeichnen von 
Ellipsen, Optimierungen, Clipping) 

= Bereiche füllen (Füllen mit waagrechten Linien und 
andere Füllalgorithmen im Vergleich) 

= Textanzeige im Grafikmodus (Zeichendefinitionen, Zei- 
chengeneratoren) 

= Alphanumerische Zeichensätze (Zeichendefinitionen in 
RAM und ROM, Veränderung der Zeichendefinitionen, 
Grafiken im Textmodus) 

= Bitblöcke und Animation (Verschiebung von Bitblöcken, 
Pixeloperationen, Animation, Cursor im Grafikmodus) 


= Besonderheiten (Routinen zur Behandlung des Vertikal- 
Interrupts, Light Pen) 

Grafikroutinen in Hochsprachen 

Übersicht über das Bildschirm-BIOS 
Bildschirm-Hardcopy (Routinen für CGA und EGA) 
Feststellen des Bildschirmadapters (alle Adapter) 


Vor allem die Besitzer von Hercules-Adaptern werden 
es schr zu schätzen wissen, daß endlich einmal auch dieser 
Bildschirmadapter in einer seiner Verbreitung würdigen 
Ausführlichkeit beschrieben wird. 

Wer professionelle Software für PCs entwickeln möchte, 
sei es als Amateur oder Profi, der benötigt dieses Buch. Es 
ist fast nur Positives darüber zu sagen. Einziger Nachteil des 
Buchs: Die Listings sind in einem äußerst hellen grün ge- 
druckt, so daß sie nur sehr schwer zu lesen sind. Dies ist 
umso nachteiliger, da man das Buch wegen seiner Ausführ- 
lichkeit und seines Detailreichtums immer wieder zu Hand 
nehmen und häufig darin lesen wird. 

Für PC-Programmierer ist »Video Systems« sicherlich 
eine der wichtigsten - wenn nicht sogar die wichtigste - 
Neuerscheinung. Sobald die deutsche Übersetzung, die 
beim Vieweg-Verlag erscheinen wird, weit genug gediehen 
ist, werden wir »zum Einlesen« einen Auszug aus diesem 
sehr interessanten Buch drucken. 


Richard Wilton: »The programmer’s guide to PC and PS/2 
video systems. Maximum performance from the EGA, VGA, 
HGC, and MCGA«, Redmond: Microsoft Press, 1987; 530 
Seiten; ISBN 1-55615-103-9; $24.95. 5'4- oder 3%%-Zoll-Dis- 
kette zum Buch 825.95 (inkl. Versandkosten). 


Probleme mit dem Bildschirmadapter stellen sich für Win- 
dows-Programmierer nicht, doch dafür hat Windows einige 
andere Hürden, die zu nehmen sind, bevor man erfolgreich 
Windows-Programme schreiben kann. Da sind vor allem 
der Umfang (fast 500 Funktionen) und auch die gänzlich 
neue, ereignisgesteuerte Programmierphilosophie von 
Windows zu nennen. Im Microsoft System Journal hat vor 
allem Charles Petzold mehrmals Licht in das Dunkel der 
Windows-Programmierung gebracht. Charles Petzold hat 
nun sein Windows-Programmierwissen in einem 800-Seiten- 
Wälzer mit dem Titel »Programming Windows« gesammelt. 
Wer die Artikel von Charles Petzold im MSJ gelesen hat, 
weiß, daß er komplexe Zusammenhänge anschaulich dar- 
stellen kann. Das ist ihm in größerem Maßstab auch mit 
»Programming Windows« geglückt, einem Buch, daß 
sicherlich für lange Zeit ein Standardwerk für Windows- 
Programmierer sein wird. 

Besonders hervorzuheben sind der didaktische Aufbau 
des Buchs, die ausführliche Beschreibung der einzelnen 
Themenkomplexe und die über 60 sehr nützlichen Beispiel- 
programme, die dabei fast mühelos nebenbei entstehen. 
Wenn Sie unter Windows programmieren wollen, brauchen 
Sie dieses Buch. 
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Buchbesprechungen 


Es empfiehlt sich, zu diesem Buch auch gleich die Dis- 
kette zu bestellen, da die entwickelten Programme und 
Funktionen keine praxisfernen Beispiel sind, sondern 
meistens sehr sinnvoll zur Bereicherung eigener Program- 
me verwendet werden können. Einige Programme wurden, 
meist nicht ganz so ausführlich, bereits im MSJ vorgestellt. 


= Übergabe von Bildschirminhalten an andere Programme 
(BlowUp, s. MSJ Noy. ’87, $.56) 

= Anzeige des freien Speichers (FreeMem in dieser Aus- 

gabe) 

Digitaluhr 

Farbeinstellungen (ColorSecr, s. MSJ März ’88, S.34) 

Grafiken und Fonts in Menüs 

Dialogboxen zur Dateinamenauswahl 

ein hexadezimaler Taschenrechner (HexCalc, s. MSJ 

März ’88, $.34) 

Abfrage von Systeminformationen 

Grafiken unter Windows 

Grafikanimation 

Schriftauswahl und Anzeige proportionaler Schriften 

Grafikdruck und Bildschirm-Hardcopy 

Laden und speichern der Zwischenablage (Clipboard) 

Verwaltung von Ressourcenbibliotheken 


Charles Petzold: »Programming Windows. The Microsoft 
Guide to programming for the MS-DOS Presentation Mana- 
ger: Windows 2.0 and Windows/386«, Redmond: Microsoft 
Press, 1988; 852 Seiten; ISBN 0-914845-91-8; $24.95. 5%- 
oder 3'%-Zoll-Diskette zum Buch $33.95 (inkl. Versand- 
kosten). 


Was Windows-Programmierer an Mehraufwand zu leisten 
haben, macht sich für Windows-Anwender bezahlt. Doch 
auch unter Windows gibt es viele Tips, Tricks und Kniffe, 
die einem den Umgang erleichtern können. Viele dieser 
Tips hat Jim Heid in seinem Buch »Power Windows« ge- 
sammelt und er bietet sie dem Leser übersichtlich eingeteilt 
und in gut lesbarer Form dar. Besonders Themen wie der 
Druck auf verschiedenen Ausgabegeräten (speziell Laser- 
drucker) und die Installation von Softfonts dürften für viele 
Leser (vor allem im DTP-Bereich) interessant sein. 
Beschreibungen der wichtigsten Windows-Anwendungen 
(Excel, PageMaker, Designer, Pro3D uva.) und der Beson- 
derheiten von Windows/386 runden das positive Gesamt- 
bild ab. 

Wer Windows häufiger verwendet, sollte sich dieses 
Buch zulegen, denn er wird viele Dinge effektiver gestalten 
können, Die zahlreichen detaillierten Beschreibungen von 
internen Vorgängen und Verhaltensweisen machen das 
Buch auch für Programmierer interessant. 


Jim Heid: »Power Windows. Maximizing the speed and perfor- 
mance of Windows 2.0 & Windows/386«, Redmond: Micro- 
soft Press, 1988; 290 Seiten; ISBN 1-55615-008-3; 819.95. 
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Geballte OS/2-Informationen 


Auch OS/2-Programmierer kommen bei den Neuerschei- 
nungen des Frühjahrs ’88 nicht zu kurz. Hier beeindruckt 
auf den ersten Blick vor allem die Fachkompetenz der 
Autoren. Für Microsoft Press schreibt Gordon Letwin, der 
Chefentwickler von Microsoft für OS/2 (»Inside OS/2«), 
bei Osborne McGraw-Hill ist es Ed Iacobucci, der Leiter 
des OS/2-Entwicklungsteams bei IBM (»OS/2 Program- 
mer’s Guide«). Die Lektüre von »Inside OS/2« ist jedem zu 
empfehlen, der sich für OS/2 interessiert, für OS/2- 
Programmierer stellt sie sogar ein unbedingtes Muß dar, 
denn Gordon Letwin scheut sich nicht, auch über noch nicht 
angekündigte Zukunftspläne zu reden. Ein Beispiel dafür 
(»Das Dateisystem von OS/2«) finden Sie im Anschluß an 
diese Besprechung. 

In diesem Buch geht es weniger darum, konkrete Pro- 
grammbeispiele oder Programmieranweisungen zu geben, 
sondern mehr darum, einen Überblick über die derzeitigen 
Möglichkeiten, neuen Konzepte und zukünftigen Ent- 
wicklungen von OS/2 zu bieten und darauf hinzuweisen, 
welche Auswirkungen das auf die Programme und welche 
Folgen es für Programmierer hat. Für ein tiefgreifendes 
Verständnis von OS/2 ist das Buch sehr wichtig. 


Gordon Letwin: »Inside OS/2«, Redmond: Microsoft Press, 
1988; 290 Seiten; ISBN 1-55615-117-9; $19.95. 


Ed Iacobucci wendet sich mit seinem »OS/2 Programmers 
Guide« vor allem an die OS/2-Programmierer, im Beson- 
deren an die Assemblerprogrammierer. Ihm geht es darum, 
eine möglichst umfassenden Überblick über die Funktionen 
und Möglichkeiten von OS/2 in der Version 1.0 zu geben. 

Assemblerprogrammieren bietet der »OS/2 Program- 
mers Guide« viele Informationen, die so in der OS/2- 
Dokumentation nicht geboten werden, da diese schr stark 
auf die C-Programmierung ausgerichtet ist. Für Program- 
mierer, die andere Sprachen verwenden, ist nur etwa die 
Häfte des Buchs interessant (wobei das »nur« bei 1100 
Seiten sicherlich schr relativ zu verstehen ist). 

Ein großer Nachteil des Buchs ist, daß darin (wie bei 
IBM üblich) keinerlei Zukunfsaussichten beschrieben 
werden, selbst auf den Presentation Manager und seine 
Auswirkungen auf die Programmierung wird nirgends aus- 
führlich eingegangen. Insofern sollte das Buch unbedingt in 
Kombination mit »Inside OS/2« gelesen werden. Dann ist 
es durchaus empfehlenswert. 

Übrigens sollte man sich nicht von der sehr ähnlichen 
äußeren Aufmachung des Buchs »Using OS/2« von Kris 
Jamsa (ebenfalls erschienen bei Osborne McGraw-Hill) 
täuschen lassen. »Using OS/2« ist der totale Gegensatz von 
»OS/2 Programmer’s Guide«, ein schludrig gemachter 
»Schnellschuß«, der sein Geld nicht wert ist. 


Ed Iacobucci: »0S/2 Programmer's Guide.«, Berkeley: Os- 
bome McGraw-Hill, 1988; 1100 Seiten; ISBN 0-07-881300-X; 
824.95. 5)4- oder 31-Zoll-Diskette zum Buch $24.95. 








Das Dateisystem von OS/2 


Gordon Letwin ist der Chefentwickler für OS/2 
bei Microsoft. Er beschreibt in den folgenden 
beiden Kapiteln aus seinem Buch »Inside OS/2« 
das Dateisystem und macht auf zukünftige Ent- 
wicklungen und ihren Einfluß auf Anwendungs- 
programme aufmerksam. 


Dateiverwaltung 


Die Dateiverwaltungssysteme von OS/2 und MS-DOS 
unterscheiden sich voneinander. In OS/2 wird ein einheit- 
liches Schema zur Vergabe von Namen im ASCII-Format 
für Objekte wie Dateien, Semaphore, gemeinsame Spei- 
cherbereiche usw. verwendet. Dieses Konzept wird im fol- 
genden erläutert. 


Dateinamen 


Bevor die Namensvergabe unter OS/2 erklärt wird, soll das 
Format der Dateinamen unter MS-DOS angesprochen 
werden. Unter MS-DOS besitzen Dateinamen das 8.3-For- 
mat, mit einem Namensfeld (maximal 8 Zeichen) und 
einem Erweiterungsfeld (maximal 3 Zeichen). Der Punkt 
zwischen dem Namen und der Erweiterung ist nicht Teil 
des Dateinamens, sondern ein Begrenzungszeichen. Der 
Dateiname kann ausschließlich Großbuchstaben beinhalten. 
Bei dem Versuch, einen Dateinamen anzulegen, der Klein- 
buchstaben oder eine Mischung aus Klein- und Großbuch- 
staben enthält, konvertiert MS-DOS den Dateinamen voll- 
ständig in Großbuchstaben. Zu lange Dateinamen werden 
von MS-DOS abgeschnitten. Das Betriebssystem achtet auf 
die strenge Einhaltung der Regeln und bestimmt dabei auch 
die Struktur auf der Diskette bzw. Platte. Das Dateiverwal- 
tungssystem, das von MS-DOS Version 3.x unterstützt wird, 
ist die Dateibelegungstabelle (FAT für file allocation table). 
Im folgenden finden Sie typische MS-DOS- und OS/2- 
Dateinamen: 
\FUSSBALL\SRC\KERNEL\SCHED.ASM 

Fussball steht hier stellvertretend für ein Projekt. Der 
Pfadname führt zum Zeitplan (Scheduler) für das Projekt. 
\MEMOS\286 \MODUS.TXT 

In diesem Memo werden die Modi des 80286 behandelt. 
\\HAGAR \ ZWISCHEN \GORDON\FUERMARK 

Der Name beschreibt eine Datei in einem Zwischen- 
speicherverzeichnis auf dem Netzwerk-Server HAGAR, die 
dort vom Benutzer Mark angelegt wurde. 


1 Die Festlegungen bezüglich des Umfangs von Dateinamen gehen auf 
die Digital Equipment Corporation (DEC) zurück. Die ersten von 
DEC konstruierten Computer verwendeten die sog. RADSO-Technik 
zur Speicherung von drei Großbuchstaben in einem 16-Bit-Wort. 
Daher bot es sich an, im Dateiverwaltungssystem nur Dateinamen aus 
sechs Zeichen und Namenerweiterungen aus drei Zeichen zu erlau- 
ben. CP/M hat diese Dateinamenstruktur übernommen. Da CP/M 
aber nicht RADSO als Format verwendete, durfte der Dateiname 
»großzügigerweise« sogar acht Zeichen umfassen; die drei Zeichen 
lange Erweiterung blieb erhalten. 


Unter OS/2 sieht die Dateiverwaltung anders aus. Für 
Mikrocomputer in der Leistungsklasse, die zunehmend 
verfügbar wird, ist das geschilderte einfache Dateiverwal- 
tungssystem unzureichend. Hier ist beispielsweise an Peri- 
pheriegeräte wie WORM-Laufwerke? zu denken, die eine 
spezielle Dateiverwaltung benötigen. Aus diesem Grund ist 
das Dateiverwaltungssystem in OS/2 nicht fester Bestand- 
teil des Betriebssystems. Vielmehr verfügt OS/2 über ein 
installierbares Dateiverwaltungssystem (IFS für installable 
file system). Ein IFS ähnelt einem Einheitentreiber, der 
entsprechende Programmcode wird beim Start von OS/2 
geladen. Die Kommunikation zwischen dem IFS und OS/2 
erfolgt über die Standardschnittstelle; das Dateiverwal- 
tungssystem stellt die Software zur Verwaltung des Datei- 
systems der Speichermedien einschließlich der Möglichkei- 
ten zum Anlegen und Warten von Verzeichnissen, Belegen 
von Diskettenkapazität usw. bereit. 

Sofern Sie mit OS/2 Version 1.0 vertraut sind, wird 
Ihnen das IFS-Konzept seltsam vorkommen, da es im 
Handbuch keine Erwähnung findet. Der Grund: Die Imple- 
mentierung hinkt der architektonischen Konzeption zeitlich 
hinterher. OS/2 wurde jedoch von Anfang an auf die Unter- 
stützung installierbarer Dateiverwaltungssysteme hin aus- 
gelegt, von denen eines das bekannte FAT-Dateiverwal- 
tungssystem sein kann. Dateiverwaltungssystemaufrufe wie 
DosOpen und DosClose wurden vor diesem Hintergrund 
implementiert. Die strenge Zeitplanung und der daraus 
resultierende Druck veranlaßten uns, OS/2 Version 1.0 aus- 
schließlich mit einem FAT-Dateisystem ausgestattet auszu- 
liefern - eine künftige Version wird das vollständige IFS- 
Paket enthalten. Zum Zeitpunkt, da das vorliegende Buch 
verfaßt wurde, liegt die offizielle Ankündigung von IFS noch 
in der Zukunft. Informationen hierüber sind aber für die 
‚Anwendungsentwicklung unter OS/2 notwendig, daher sol- 
len sie im folgenden gegeben werden. 

Da das IFS Datei- und Pfadnamen interpretieren wird 
und installierbare Dateiverwaltungssysteme große Unter- 
schiede aufweisen können, enthält OS/2 selbst (abgesehen 
vom IFS) keine Informationen über das Format und die 
Bedeutung von Datei- und Pfadnamen. Das Datei- und 
Pfadnamenformat wird vom IFS selbständig verwaltet, 
sowohl das Anwendungsprogramm als auch OS/2 stellen 
Zwischenschritte dar, denen keine diesbezüglichen Infor- 
mationen zur Verfügung gestellt werden müssen. Sie sollten 
nicht den Versuch unternehmen, Datei- und Pfadnamen zu 
zerlegen, da das IFS auch Namen in anderen Formaten als 
dem 8.3-Format von MS-DOS unterstützt. Selbst auf eine 
feste Länge für einen Datei- oder Pfadnamen kann man 
sich nicht verlassen. Alle OS/2-Dateinamen- und Pfad- 





2  WORM-Laufwerke (write once read many) enthalten im allgemeinen 
Laserplatten mit hoher Kapazität. Eine einmal beschriebene Spur 
kann nicht mehr gelöscht werden. Dennoch läßt sich der Eindruck der 
Löschbarkeit erwecken, indem neue Versionen von Dateien und Ver- 
zeichnissen nach einer Veränderung erneut aufgezeichnet und die 
alten Versionen abgekoppelt werden. 
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namenschnittstellen (wie DosOpen, DosFindNext) wur- 
den auf die Übernahme von Zeichenketten beliebiger 
Länge ausgelegt. Anwendungsprogramme sollten Namen- 
puffer mit einer Länge von mindestens 256 Zeichen ver- 
wenden, damit sichergestellt ist, daß lange Dateinamen 
nicht abgeschnitten werden. 


Netzwerkzugriff 

Eine Länge von 256 Zeichen zur Speicherung eines Datein- 
amens erscheint auf den ersten Blick etwas übertrieben. 
Andererseits enthalten OS/2-Dateinamen oft Pfadnamen, 
die schr lang werden können. Um einen transparenten Zu- 
griff auf Dateien in einem LAN (local area network) zu 
erlangen, bindet OS/2 das Netzwerk als Teil des Dateiver- 
waltungssystems ein. Mit anderen Worten: Ein Pfadname 
kann neben einem Verzeichnispfad auch einen Geräte- 
namen enthalten. Ein Anwendungsprogramm könnte einen 
Öffnungsaufruf mit einem Namenstring wie 
\ARBEIT\BUCH.DAT 

‚oder 
\\vOoGON\TEMP \NEUBER . ASM 

ausgeben. Der erste Name spezifiziert die Datei 
BUCH.DAT im Verzeichnis ARBEIT des aktuellen Lauf- 
werks des lokalen Gerätes. Der zweite Name spezifiziert die 
Datei NEUBER.ASM im Verzeichnis TEMP des Gerätes 
VOGON?. Künftige Versionen des Microsoft LAN Manager 
werden das Dateiverwaltungssystem von OS/2 nutzen, so 
daß Dateinamen (insbesondere programmgenerierte Datei- 
namen) schnell sehr lang werden können. 


Namensgenerierung und Kompatibilität 


‚Anwendungsprogramme sollten idealerweise das Format 
der vom Benutzer eingegebenen Dateinamen außer acht 
lassen. Dies ist natürlich unrealistisch. Programme müssen 
oftmals selbst Dateinamen generieren (zur Zwischenspei- 
cherung von Daten, zur Aufnahme abgeleiteter Dateinamen 
usw.). Wie kann eine Anwendung Dateinamen anlegen oder 
verändern und dennoch die Kompatibilität mit allen instal- 
lierbaren Dateiverwaltungssystemen gewährleisten? Die 
‚Antwort: Verwenden Sie den ältesten Standard, von dem 
Sie sicher annehmen können, das er von allen Systemen 
unterstützt wird. Ein neues IFS wird FAT-Dateinamen (im 
8.3-Format) akzeptieren, da es andernfalls mit vielen 
anderen Programmen inkompatibel wäre. Wenn ein An- 
wendungsprogramm sich auf die 8.3-Formatregel beim 
Anlegen von Dateinamen beschränkt, ist die Kompatibilität 
mit künftigen Dateiverwaltungssystemen sichergestellt. Im 
Gegensatz zu MS-DOS schneidet OS/2 (genauer: das 
Dateiverwaltungssystem von OS/2) den Dateinamen oder 
die Erweiterung nicht ab, wenn diese zu lang sind; statt des- 


3 Die Benennung von Netzwerken ist komplizierter: Der Name TEMP 
des Gerätes VOGON bezicht sich auf die verfügbare Netzwerk-Res- 
source und kann in einem beliebigen aktuellen Verzeichnis stehen. 
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sen wird ein Fehler gemeldet. Die Groß-/Kleinschreibung 
eines Dateinamens wird auch weiterhin ohne Signifikanz 
bleiben. Einige Betriebssysteme wie UNIX unterscheiden in 
Dateinamen zwischen Groß- und Kleinbuchstaben. Die 
Namen Arbeit und arbeit bezeichnen in Unix unter- 
schiedliche Dateien. Diese Methode funktioniert, solange 
ein System durchweg von Programmierern genutzt wird. 
Für einen Softwareentwickler ist es selbstverständlich, daß 
es sich bei dem Kleinbuchstaben f (ASCII-Code 66 hex) 
und dem Großbuchstaben F (ASCII-Code 46 hex) um 
unterschiedliche Zeichen handelt. Für einen unbedarften 
Benutzer hingegen bezeichnen f und F den gleichen Buch- 
staben. Da der Großteil der OS/2-Anwender keine Pro- 
grammierer sein werden, wird das installierbare Dateiver- 
waltungssystem von OS/2 keine Unterscheidung bezüglich 
der Groß-/Kleinschreibung vornehmen. 

Wie bereits ausgeführt, sollten programmgenerierte 
Namen der 8.3-Formatregel folgen, um Komplikationen von 
vornherein auszuschließen. Ebenfalls aus Sicherheitsgrün- 
den empfiehlt es sich, Programmnamen nur derart zu modi- 
fizieren, daß alphanumerische gegen andere alphanumeri- 
sche Zeichen ausgetauscht werden (zum Beispiel: AR- 
BEIT.OBJ gegen ARBEIT.ASM). Die Verlängerung von 
Dateinamen ist auch möglich (zum Beispiel ARBEIT.C 
nach ARBEIT.OBJ), wenn das Programm den neuen 
Namen auf seine Gültigkeit hin untersucht. Falls sich der 
Name als ungültig erweisen sollte, muß eine Korrektur- 
möglichkeit zur Verfügung stehen. In jedem Fall sollte das 
Programm erweiterte Dateinamen verarbeiten können. In 
een oben genannten Substitutionsfällen ist es ratsam, daß 
der Algorithmus vom Ende der Zeichenkette her arbeitet. 


Berechtigungen 


In künftigen OS/2-Versionen wird das Dateiverwal- 
tungssystem nicht nur zur Bezeichnung von Dateien ver- 
wendet werden können, sondern auch zur Vergabe von Zu- 
griffsberechtigungen. Ein Algorithmus wird eine Zugriffs- 
liste mit jedem Eintrag im Dateinamenbereich verknüpfen, 
so daß der unautorisierte Zugriff (verschentlich oder vor- 
sätzlich) auf die genannte Datei unterbunden wird. 


‚Andere Objekte im Dateinamenbereich 


Die Bedeutung des Dateinamenbereiches wurde bereits 
anhand mehrerer Aspekte beleuchtet. Zum einen erlaubt 
der Bereich die Benutzung einer Vielzahl unterschiedlicher 
Namen. Namen können gruppiert werden (durch das Spei- 
chern im gleichen Verzeichnis) und es lassen sich Familien 
von einheitlichen Namen (durch das Anlegen neuer Unter- 
verzeichnisse) angelegen. Zum zweiten kann der Namen- 
bereich alle Dateien und Einheiten des lokalen Rechners 
ebenso wie die Dateien und Einheiten von Remote-Syste- 
men umfassen. Schließlich werden Dateisystemnamen 
künftig einen flexiblen Zugriffsschutz unterstützen. 


Es ist keine Überraschung, daß die Entwickler bei der 
Suche nach Methoden für die Benennung von Objekten, die 
keine Dateien darstellen (gemeinsam benutzte Speicher- 
bereiche, Systemsemaphore und benannte Pipes), auf den 
Dateisystemnamenbereich zurückgegriffen haben. Ein 
Nachteil dieser Entscheidung ist darin zu schen, daß 
Dateien und Objekte, die keine Dateien darstellen, unter- 
schiedliche Namen aufweisen müssen. Ein vergebener 
Dateiname kann nicht mehr für einen gemeinsam genutzten 
Speicherbereich, ein Systemsemaphor oder eine benannte 
Pipe verwendet werden, was allerdings verglichen mit den 
Vorteilen der gemeinsamen Benutzung des Dateisystem- 
namenbereichs kaum relevant ist. Zudem können für jeden 
Objekttyp eigene Unterverzeichnisse verwendet werden, so 
daß Überlappungen von vornherein ausgeschlossen sind. 

Bedeutet dies, daß Systemsemaphore, gemeinsam 
genutzter Speicher und Pipes Dateisystemeinträge auf einer 
Diskette/Festplatte besitzen? Das FAT-Dateisystem unter- 
stützt in seinen Verzeichnissen keine Sonderobjektnamen. 
Eine Veränderung in dieser Richtung wäre leicht möglich, 
doch wäre das FAT-Dateisystem dann nicht mehr abwärts- 
kompatibel (MS-DOS 3.x könnte Disketten/Platten, die 
unter OS/2 beschrieben wurden, nicht lesen). Da für OS/2 
Version 1.0 nur das FAT-Dateiverwaltungssystem verfügbar 
ist, enthält diese Version RAM-residente Pseudoverzeich- 
nisse, die Objektnamen aufnehmen. Die Namen müssen mit 
\SEM\, \SHAREMEM\, \QUEUES\ und \DEV\ beginnen, um 
die Gefahr der Namenskollision mit Dateien in künftigen 
Versionen von OS/2 zu minimieren. 

Obgleich Leistungsmerkmale wie Netzwerkbetrieb und 
(zukünftig) Zugriffsschutz zum Dateisystemnamenbereich 
gehören (vom Standpunkt der Architektur her), werden 
nicht alle Permutationen unterstützt. Insbesondere die 
Unterstützung von benannten, gemeinsam benutzten 
Speicherbereichen über ein Netzwerk ist nur mit schr viel 
Aufwand zu realisieren.* Dieses Leistungsmerkmal wird 
daher auch künftig in OS/2 nicht implementiert werden. 


Das Dateisystem 


Das Dateisystem von OS/2-Version 1.0 unterscheidet sich 
nur geringfügig von dem des MS-DOS-Systems. Dies 
erklärt sich in erster Linie aus der gewünschten Kompatibi- 
lität zu MS-DOS-Programmen. Auf der anderen Seite 
waren die Zeitvorgaben zur Entwicklung von OS/2 recht 
knapp. Der Zeitrahmen war nicht ausreichend, um in der 
ersten OS/2-Version alle gewünschten Leistungsmerkmale 
unterzubringen, Erweiterungen des Dateisystems sind für 





4 Dies hängt damit zusammen, daß das gesamte Speichersegment bei 
jeder Änderung im Netzwerk übertragen werden muß. Durch eine 
Reihe von Optimierungsmaßnahmen läßt sich der Aufwand reduzie- 
ren, was aber immer noch nicht zu einem vernünftigen Aufwand/ 
Nutzen-Verhältnis führt. 





künftige Versionen geplant. Im folgenden will ich eine 
Erklärung liefern, weshalb ein so wichtiger Punkt wie ein 
neues Dateiverwaltungssystem aufgeschoben wurde. 

Die Mikrocomputerbranche entwickelte sich in zwei 
Richtungen: Massensoftware und Standards. Die 
»massenhafte« Vermarktung von Software erlaubt den Kauf 
hochentwickelter Programme für relativ wenig Geld - der 
Ausdruck wenig Geld muß hier im Vergleich zu den Ent- 
wicklungskosten geschen werden, die oftmals Millionen 
Dollar betragen. Die Massenvermarktung unterstützt die 
Standardisierung, da kein Benutzer System, Peripherein- 
heiten und Geräte kaufen will, die mit den weithin ange- 
botenen Programmen nicht kompatibel sind. Andererseits 
unterstützt die Akzeptanz der Standards die Entwicklung 
von Massensoftware, so daß das Absatzpotential für Pro- 
gramme immens zunimmt. In diesem Kreislauf eröffnet sich 
die Chance zur Entwicklung äußerst komplexer Anwendun- 
gen, da die hohen Gestehungskosten durch einen breiten 
Massenmarkt abgefangen werden. 

Der Synergieeffekt zwischen Standardisierung und Mas- 
senvermarktung von Software betrifft natürlich auch die 
Betriebssystementwicklung. Auf den ersten Blick scheint 
das Hinzufügen neuer Leistungsmerkmale zu einem 
Betriebssystem problemlos. Die Entwickler bauen neue 
Leistungsmerkmale in eine neue Version ein und die 
Anwendungen werden zur Nutzung der neuen Leistungs- 
merkmale umgeschrieben. Mit der Massenvermarktung von 
Software ist dies allerdings nicht möglich. Microsoft könnte 
eine neue Version von OS/2 mit einigen neuen Leistungs- 
merkmalen herausbringen (und tatsächlich wird dies auch 
der Fall sein), anfänglich würden aber nur wenige Anwen- 
dungen die neuen Leistungsmerkmale nutzen. Dies beruht 
auf der begrenzten Marktdurchdringung der neuen Version. 
Nach einer bestimmten Zeit nach der Verfügbarkeit der 
neuen Version haben vielleicht zehn Prozent der OS/2- 
Benutzer ihre Version aktualisiert. Ein ISV (Independent 
Software Vendor), der ein neues Produkt plant, hofft natür- 
lich auf einen Bestseller. Er muß entscheiden, ob das Pro- 
dukt die neuen Leistungsmerkmale ansprechen und damit 
nur zehn Prozent des potentiellen Marktes adressieren soll. 
Die Alternative besteht in der Verwendung der Leistungs- 
merkmale der verbreiteten Betriebssystemversion, was das 
Programm auf allen derzeitigen Systemen ausführbar macht 
(inklusive der zehn Prozent, die neueste OS/2-Versionen 
verwenden). Im allgemeinen werden Softwareanbieter die 
nicht verbreiteten Leistungsmerkmale eines Betriebssytems 
in ihrem Programm nicht einsetzen, bis die Mehrheit der 
existierenden Systeme diese unterstützen. 

Der Schlüssel zur Einführung neuer Leistungsmerkmale 
in einem Betriebssystem ist also nicht die Verfügbarkeit 
oder Nützlichkeit. Der Schlüssel besteht darin, daß die Ver- 
sion mit den neuen Leistungsmerkmalen möglichst rasch 
eine große Marktdurchdringung erlangt. Falls dies nicht der 
Fall ist, wird das neue Leistungsmerkmal nicht verwendet. 
‚Aus diesem Grunde wurden neue MS-DOS-Versionen nur 
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herausgegeben, wenn die Unterstützung neuer Hardware- 
elemente erforderlich wurde. MS-DOS Version 2.0 wurde 
für die IBM XT-Produktlinie benötigt. MS-DOS Version 
3.0 muß der AT-Produktreihe zugerechnet werden. OS/2 
stellt keine Ausnahme dar: Das Betriebssystem soll den 
Protect-Modus der Rechner mit dem Intel-Prozessor 80286 
unterstützen. Falls eine neue Version eines Systems nur 
neue Leistungsmerkmale enthält, die nicht unbedingt 
gebraucht werden, ist die Marktdurchdringung anfänglich 
sehr niedrig und verbessert sich nur langsam. Die Kosten 
zur Aktualisierung sind nur gerechtfertigt, wenn die neuen 
Leistungsmerkmale unabkömmlich sind. Anwendungspro- 
gramme fordern die Verfügbarkeit neuer Leistungsmerk- 
male häufig erst, wenn die Verbreitung groß genug ist. 

In den Augen der Entwickler ist die erste Version von 
0S/2 damit sehr wichtig. Durch sie ist eine Möglichkeit zur 
Einführung neuer Leistungsmerkmale in den Betriebs- 
systemstandard der PCs eingeführt. Dieses »Fenster« wird 
für lange Zeit nicht mehr so weit geöffnet sein. 

Aus diesem Grund wurde die Erneuerung des Datei- 
verwaltungssystems zurückgestellt: Das Dateiverwaltungs- 
system kann in späteren Versionen erweitert und verbessert 
werden, wobei existierende Anwendungen ohne Änderun- 
gen weiterhin unterstützt werden. Viele andere OS/2-Lei- 
stungsmerkmale mußten dagegen unbedingt in die erste 
Version des Betriebssystems aufgenommen werden, da sie 
sonst für Massenanwendungen niemals verfügbar werden 
würden. 


Das OS/2-Dateiverwaltungssystem 


Einige kleinere Änderungen wurden am Dateiverwal- 
tungssystem von OS/2 Version 1.0 durchgeführt. Zwei 
davon sind der Erwähnung wert: Die erste ist die asyn- 
chrone Ein- und Ausgabe, die zwei Funktionen umfaßt 
(DosReadAsync und DosWriteAsync). Die Funktionen 
entsprechen den DosRead- und DosWrite-Aufrufen mit 
der Ausnahme, daß sie die Kontrolle sofort an das aufrufen- 
de Programm zurückgeben (üblicherweise vor der Vervoll- 
ständigung der Ein-/Ausgabeoperation). Die Funktionen 
übernehmen die Nummer eines Semaphors, das nach der 
Beendigung der Ein-/Ausgabeoperation gelöscht wird. Die 
Threads des aufrufenden Prozesses können das Semaphor 
zur Überprüfung der Ein-/Ausgabebeendigung verwenden. 
Die Funktion DosMuxSemWait ist in diesem Zusammen- 
hang besonders nützlich, da sie das Warten auf mehrere 
Semaphorenereignisse erlaubt, die auch asynchrone Ein-/ 
Ausgabe-, IPC- und Zeitgeberereignisse beinhalten dürfen. 

Das zweite neue Leistungsmerkmal des Dateiverwal- 
tungssystems ist eine erweiterte Partitionierung: Die Unter- 
stützung umfangreicher physikalischer Laufwerke in Form 
von mehreren Bereichen ist gewährleistet, wobei mehrere 
Partitionen FAT-Dateiverwaltungssysteme enthalten kön- 
nen. Die Folge ist, daß OS/2 eine große Festplatte als zwei 
oder mehrere kleinere Einheiten betrachten kann, von 
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denen jede der Größenbeschränkung des Dateiverwaltungs- 
systems unterliegt. Der Aberglaube, daß MS-DOS nur 
Laufwerke bis zu einer Größe von 32 Mbyte verwenden 
kann, ist weit verbreitet. Dies ist allerdings nicht richtig. Die 
Begrenzung liegt darin, daß ein Laufwerk in nicht mehr als 
65.535 Sektoren aufgeteilt werden kann. Aus der Standard- 
sektorgröße von 512 Bytes ergibt sich der Wert von 32 
Mbyte. Hinzu kommt, daß jeder Datenträger auf 32.768 
Cluster begrenzt ist. Ein Scktor ist eine Einheit des Disket- 
tenspeicherplatzes; Disketten können immer nur in ganzen 
Sektoren gelesen und geschrieben werden. Die Größe der 
Sektoren wird bei der Formatierung des Datenträgers fest- 
gelegt. Ein Cluster ist die Einheit, in der die Speicherkapa- 
zitätsbelegung für Dateien und Verzeichnisse erfolgt. Ein 
Cluster kann aus cinem oder mehreren vollständigen Sekto- 
ren bestehen. Das MS-DOS-Dateiverwaltungssystem 
erlaubt ein Maximum von 65 Kbyte pro Sektor, während 
nur 32 Kbyte für Cluster erlaubt sind. Folglich muß cine 32- 
Mbyte-Platte in Clustern zu zwei (oder mehr) Scktoren 
belegt werden. Die Entwicklung von Einheitentreibern, die 
als Scktorgröße ein Mchrfaches von 512 Bytes unterstützen, 
erlaubt die Umgehung der 65-Kbyte-Scktorbeschränkung 
und dadurch die Verwendung einer Festplatte, die mehr als 
32 Mbyte Kapazität enthält. Der für MS-DOS beschriebene 
Trick kann auch unter OS/2 angewendet werden, besitzt 
aber den Nachteil, daß dies die Vergrößerung der Sektoren 
mit sich bringt, wodurch viel Speicherkapazität verschwen- 
det wird 5 

Die erweiterte Leistungsfähigkeit zur Partitionierung 
eines Datenträgers unter OS/2 Version 1.0 stellt eine Zwi- 
schenlösung dar, die den Kapazitätsverlust durch die interne 
Fragmentierung reduziert: Mchr als cine Partition kann ein 
FAT-Dateiverwaltungssystem enthalten. _ Partitionierte 
Datenträger unter MS-DOS dürfen nur eine Partition ent- 
halten, die ein MS-DOS-Datciverwaltungssystem (das heißt, 
eine FAT) besitzt. Diese Einschränkung wurde unter OS/2 
aufgehoben, so daß beispielsweise eine 60-Mbyte-Festplatte 
in zwei separate logische Laufwerke partitioniert werden 
kann (beispielsweise C und D), von denen jede eine Spei- 
cherkapazität von 30 Mbyte umfaßt. 








Verwaltung der Datenträgernamen 


Die Multitasking-Fähigkeit von OS/2 macht eine Erwei- 
terung des Dateiverwaltungssystems im Bereich der Daten- 
trägerkennsätze nötig. Ein Datenträgerkennsatz ist der 
Name, der der Diskette und den darauf enthaltenen 
Dateien zugeordnet wird. Ein nichtauswechselbares Lauf- 
werk (Festplatte) enthält stets denselben Datenträger, bei 





5 Das FAT-Dateiverwaltungssystem kann mit einem Maximum von 32- 
Kbyte-Belegungseinheiten (Clustern) arbeiten. Unabhängig von der 
Größe des Datenträgers müssen alle Dateien eine Mindestdisketten- 
kapazität von 1/32 Kbyte des Gesamtdatenträgers belegen. Dies 
bedeutet, daß eine 60-Mbyte-Festplatte unter Verwendung von 1.024- 
Byte-Sektoren 2.048-Byte-Einheiten belegt. 





einem Laufwerk mit austauschbaren Datenträgern (wie Dis- 
kettenlaufwerken) kann nicht vorhergesagt werden, welche 
Diskette vom Benutzer zu welchem Zeitpunkt eingelegt 
wird. 

Die Möglichkeit eines Diskettenwechsels wird in Multi- 
tasking-Umgebungen zu einem Problem. Verwendet ein 
Benutzer beispielsweise eine Textverarbeitung und editiert 
eine Datei auf der Diskette in Laufwerk A, hat der Editor 
die Datei geöffnet und behält diesen Status bei der Editie- 
rung bei. Ohne das Schließen der Datei oder die Beendi- 
gung des Editors kann der Benutzer die Bildschirmgruppe 
umschalten, damit beispielsweise ein Tabellenkalkulations- 
programm abläuft. In diesem Fall muß in Laufwerk A eine 
andere Diskette eingelegt werden, die Daten zur Bearbei- 
tung der Tabellenkalkulation enthält. Durch die Umschal- 
tung zum Textverarbeitungsprogramm ohne entsprechen- 
den Diskettenwechsel kommt es für das System zu nicht 
lösbaren Problemen. Die Betätigung der Taste (PgDn) läßt 
das Textverarbeitungssystem einen weiteren Sektor der 
bereits geöffneten Datei lesen. Das Betriebssystem erkennt 
- aufgrund der FAT-Informationen in den RAM-Puffern - 
daß der nächste Sektor der Textdatei der Sektor N ist und 
wird versuchen, den Sektor N der falschen Diskette zu lesen 
(der Diskette mit den Daten für die Tabellenkalkulation). 
Der gelesene Sektor wird an das Textverarbeitungspro- 
gramm als nächster Sektor der Textdatei zurückgegeben. 
Dies ist kein schwerwiegender Fehler; schlimmer wird es 
aber, wenn das Textverarbeitungssystem einen Sektor auf 
die Diskette schreibt, wodurch zwei Dateien vernichtet wer- 
den: Die Datendatei der Tabellenkalkulation wird durch 
den nicht korrekt gesteuerten Schreibvorgang zerstört und 
Gleiches gilt für die Textdatei, bei der beim nächsten Lese- 
zugriff festzustellen ist, daß die auf die falsche Diskette 
geschriebenen Daten fehlen. 

Diese Probleme können nicht dadurch gelöst werden, 
daß der Benutzer Disketten mit Bedacht einlegt; viele Pro- 
gramme lesen und schreiben ohne direkten Benutzerbefehl 
auf und von Disketten. So könnte beispielsweise die Text- 
verarbeitung die Arbeit automatisch alle zwei Minuten spei- 
chern. Nach Verstreichen dieses Zeitintervalls erfolgt ein 
vom Benutzer nicht ausdrücklich gewollter Schreibvorgang, 
auch wenn der Benutzer noch mit der Tabellenkalkulation 
und der dazugehörigen Tabellenkalulationsdiskette arbeitet. 

08/2 löst diese Probleme, indem Anwendungen ihre 
Ein-/Ausgaben an geöffnete Dateien nicht an Laufwerk A 
richten, sondern an einen bestimmten Datenträgerkennsatz 
(nämlich den, der der Diskette zugeordnet ist, auf der die 
geöffnete Datei vorliegt). Jeder Datenträgerkennsatz 
besteht aus einem Datenträgernamen, der im Stammver- 
zeichnis gespeichert ist und einer einzigartigen 32-Bit- 
Datenträgerkennummer, die sich im Startsektor befindet. In 
Bild 1 sind die beiden Teile des Datenträgerkennsatzes 
gezeigt - einen zur Verwendung durch den Computer 
(Datenträgerkennummer) und einen für den Bediener 
(Datenträgername). Jede Dateinummer wird mit einer 
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bestimmten 32-Bit-Datenträgerkennummer assoziiert. Bei 
einer Ein-/Ausgabeanforderung auf eine Dateinummer 
überprüft OS/2, ob sich der entsprechende Datenträger im 
Laufwerk befindet. Dies erfolgt durch den Vergleich des 32- 
Bit-Wertes der Anforderung mit dem des momentan im 
Laufwerk befindlichen Datenträgers. Bei übereinstimmen- 
den Nummern wird die Operation vervollständigt. Unter- 
scheiden sich die beiden Nummern, verwendet OS/2 den 
Hardwarefehler-Daemon-Mechanismus, der eine Aufforde- 
rung zum Einlegen des richtigen Datenträgers anzeigt. 

Um dies praktikabel zu machen, müssen drei Probleme 
gelöst werden. Zuerst einmal darf die Überprüfung der 
Datenträgerkennummer des Datenträgers den Durchsatz 
nicht mindern. Der Startsektor kann nicht bei jeder Ein-/ 
Ausgabeoperation gelesen werden, wenn dadurch die Ein-/ 
Ausgabegeschwindigkeit um die Hälfte gesenkt wird. Zum 
zweiten muß sichergestellt sein, daß die Datenträger- 
kennummer tatsächlich einzigartig ist und drittens muß 
auch ein Datenträger bearbeitet werden können, der keine 
Datenträgerkennummern besitzt. 
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Bild 1: Datenträgerkennummer und Datenträgename 


Die Überprüfung des korrekten Datenträgers ist ein- 
fach, wenn bekannt ist,-wann ein Datenträger gewechselt 
wurde. Es ist offensichtlich, daß die Kennummer nur nach 
einem Wechsel des Datenträgers gelesen werden sollte. Wie 
erkennt OS/2 einen Wechsel? OS/2 kann dies nicht erken- 
nen, wohl aber der Einheitentreiber. Falls die Einheit ein 
nicht austauschbares Medium erhält, muß die Datenträger- 
kennummer nicht überprüft werden. Der Einheitentreiber 
erkennt dies und antwortet mit nicht gewechselt, wenn er 
nach dem Status des Mediums gefragt wird. Einige aus- 
tauschbare Mediumtreiber besitzen ein Flagbit, das beim 
Öffnen der Laufwerksklappe gesetzt wird. In diesem Fall 
antwortet der Einheitentreiber bei einer Anfrage mit Wech- 
selstatus unbestimmt. Der Treiber erkennt nicht, ob der 
Datenträger tatsächlich ausgetauscht wurde, es könnte aber 
der Fall sein. In diesem Fall überprüft OS/2 die Daten- 
trägerkennummer. Die erneute Überprüfung der Kennum- 
mer wird noch schwieriger, wenn eine Einheit, deren 
Datenträger austauschbar sind, keinen entsprechenden 
Indikator besitzt. 
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Buchauszug 


Der Entwickler eines Einheitentreibers muß einheiten- 
spezifische Details beachten, um die minimale Zeitspanne 
zu bestimmen, in der ein Wechsel des Datenträgers auftre- 
ten kann. Ist die Einheit für Ein-/Ausgaben bereit und die 
minimal nötige Zeit zum Austausch des Datenträgers seit 
der letzten Operation noch nicht vergangen, erkennt der 
Treiber, daß noch derselbe Datenträger im Laufwerk liegen 
muß. Ist mehr Zeit vergangen, übergibt der Treiber eine 
Mediawechsel unbestimmt-Meldung an OS/2 und das 
Betriebssystem muß den Datenträger überprüfen. Für Dis- 
kettenlaufwerke beträgt dieser Zeitintervall üblicherweise 
zwei Sekunden, so daß nach dem Verstreichen dieses Zeit- 
raumes ein Extralesevorgang ausgeführt wird. Für schnell 
hintereinander erfolgende Diskettenein-/-ausgaben werden 
keine Extralesevorgänge benötigt. 

Die Sicherstellung einer einzigartigen Datenträger- 
kennummer ist ein weiteres Problem. Das Betriebssystem 
darf sich nicht darauf verlassen, daß der Benutzer keine 
Datenträgernamen doppelt vergibt. Selbst ein »perfekter 
Benutzer« kann sich eine Diskette von seinem Nachbarn 
borgen, die einen Namen trägt, den der Benutzer schon 
einmal vergeben hat. OS/2 löst dieses Problem durch die 
Verwendung einer 32-Bit-Zufallszahll als Disketten- 
kennummer. Bei der Formatierung einer Diskette gibt der 
Benutzer einen Namen ein. Von diesem Namen werden 
Prüfsummen gebildet und das Resultat, verknüpft mit der 
Anzahl der Sekunden zwischen dem aktuellen Zeitpunkt 
und dem Jahr 1980 wird als Ausgangswert für einen Zufalls- 
zahlengenerator verwendet. Der Zufallszahlengenerator 
gibt eine 32-Bit-Zahl zurück, die als Datenträgerkennum- 
mer verwendet wird. Es ist offensichtlich, daß die doppelte 
Vergabe einer Datenträgerkennummer zwar möglich ist, 
die vier Milliarden auf diese Weise zu erzeugenden Codes 
machen dies aber unwahrscheinlich. 

Der vom Benutzer eingegebene Name dient lediglich 
dazu, in späteren Eingabeaufforderungen an den Benutzer 
klarzumachen, welche Diskette eingelegt werden soll. Der 
Name muß für das System nicht tatsächlich einzigartig sein. 
Ein Benutzer, der mehrere Disketten mit dem Namen 
Arbeit verwendet, wird für OS/2 dadurch keine Probleme 
hervorrufen, da das Betriebssystem die Disketten aufgrund 
der Datenträgerkennummern als unterschiedlich erkennt. 
Das Einlegen der falschen Diskette mit Namen Arbeit als 
Reaktion auf eine Eingabeaufforderung wird von OS/2 
abgelehnt. Es wird eine erneute Aufforderung zum Einle- 
gen der Diskette ausgegeben. Nachdem das System mehr- 
mals zum Einlegen der Diskette mit dem Namen Arbeit 
aufgefordert hat, wird sich der Benutzer sicherlich zur 
Umbenennung seiner Disketten entscheiden. 

Das schwierigste Problem ergibt sich aus nicht benann- 
ten Disketten - dies sind Disketten, die unter MS-DOS for- 
matiert wurden. Es kann auch hier nicht vom Benutzer 
erwartet werden, daß den Disketten ein einzigartiger Name 
zugewiesen wird. Gleichfalls ist die automatische Benen- 
nung durch OS/2 nicht vertretbar, da Datenträger nur les- 
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bar sein können. Auch wenn dies nicht der Fall ist, ergibt 
sich das Problem mit Disketten niedriger und hoher Dichte. 
Disketten niedriger Dichte können in einem Laufwerk für 
Disketten hoher Dichte gelesen werden, Schreibvorgänge 
eines mit hoher Dichte arbeitenden Laufwerkes auf eine 
Diskette mit niedriger Dichte können aber nur von Lauf- 
werken mit hoher Dichte gelesen werden. Das Lesen der 
neuen Information durch Laufwerke niedriger Dichte ist 
nicht sichergestellt und der Startsektor ist bei der Verwen- 
dung eines Laufwerkes niedriger Dichte unter Umständen 
nicht mehr lesbar. 

Für Datenträger ohne korrekte Datenträgerkennummer 
versucht OS/2 die Erstellung einer einzigartigen Substituti- 
onsdatenträgerkennummer, indem Prüfsummen von Teilen 
des Stammverzeichnisses und der FAT-Tabelle gebildet 
werden. OS/2 verwendet dabei den Datenträgernamen 
(sofern existent). Ist kein Datenträgername verhanden, ver- 
sucht OS/2, die Diskette zu beschreiben. Keine der Metho- 
den ist narrensicher und sie erfordern mehrere Disket- 
tenzugriffsoperationen bei der Verifikation eines Daten- 
trägers. Die beste Abhilfe besteht darin, Disketten, die in 
OS/2-Systemen zum Einsatz gebracht werden sollen, mit 
Namen zu versehen. OS/2-Namen sind abwärtskompatibel 
zu MS-DOS Version 3.x. 

Der Befehl DISKCOPY erstellt unter OS/2 eine byte- 
identische Kopie einer Diskette. Die einzige Abweichung 
der duplizierten Diskette vom Original besteht darin, daß 
diese eine andere Datenträgerkennummer im Startsektor 
aufweist (der Datenträgername wird nicht verändert). Der 
Benutzer von OS/2 erkennt dies nicht, da die DISKCOMP- 
Utility insofern Falschangaben macht, als das zwei Disket- 
ten als identisch angeschen werden, wenn sie bis auf die 
Datenträgerkennummer übereinstimmen. Wenn ein Benut- 
zer eine Diskette mit DISKCOPY unter OS/2 dupliziert 
und Original und Kopie mit dem Befehl DISKCOMP unter 
MS-DOS 3.x vergleicht, wird ein Unterschied festgestellt. 

Die Erläuterungen haben sich bis zu dieser Stelle auf 
Lese- und Schreibvorgänge mit einer geöffneten Nummer 
beschränkt. Lese- und Schreibvorgänge sind datenträgerori- 
entierte Operationen, da sie sich immer auf den Datenträ- 
ger beziehen, auf dem die Datei vorliegt. Der DosOpen- 
Aufruf ist dagegen laufwerksorientiert, da das Standard- 
oder das spezifizierte Laufwerk nach der entsprechenden 
Datei durchsucht wird, wobei es gleichgültig. ist, welcher 
Datenträger im Laufwerk liegt. Alle Nummernoperationen 
sind laufwerksorientiert, alle Aufrufe auf Namensbasis sind 
datenträgerorientiert. Derzeit kann nicht spezifiziert wer- 
den, daß eine Datei auf einem bestimmten Datenträger 
angelegt oder geöffnet wird. Um sicherzustellen, daß eine 
Zwischen- oder Ausgabedatei auf einem bestimmten Da- 
tenträger angelegt wird, muß die Datei auf diesem Daten- 
träger geöffnet sein. Dazu wird direkt vor dem Öffnen ein 
Schreibvorgang in die Datei ausgeführt. Die Schreibope- 
ration gefolgt von einem DosBufReset-Aufruf stellt sicher, 
daß der gewünschte Datenträger im Laufwerk einliegt. 


Effizienz der Ein- und Ausgabe 


OS/2 unterstützt blockorientierte Operationen (zerlegend 
oder nicht zerlegend) bei allen Diskettenein-/-ausgabeope- 
rationen. Ein Programm kann eine beliebige Anzahl von 
Bytes lesen oder schreiben. OS/2 liest die entsprechenden 
Sektoren und internen Puffer, so daß nur die betroffenen 
Bytes geladen werden. Jeder DosRead- und DosWrite- 
‚Aufruf benötigt Ausführungszeit, daher ist es effektiver, mit 
einem Aufruf eine größere Datenmenge anzusprechen. 

Der Durchsatz bei der Ein-/Ausgabe wird nochmals 
verbessert, wenn eine Sektorgrenzanpassung ausgeführt 
wird. Das Lesen eines ganzzahligen Vielfachen von 512 
Bytes ab einer Sektorengrenze führt dazu, daß vollständige 
Sektoren ohne Zwischenspeicherung in Systempuffern an 
die Anzeigehardware übergeben werden. Da das Datei- 
system auf eine optimale Speicherung der Daten auf dem 
Datenträger achtet (logisch zusammenhängende Daten 
werden so gespeichert, daß das Lesen oder Schreiben ohne 
umfangreiche Änderung der Schreib-/Lesekopfposition 
erfolgt), ist das Lesen von vier aufeinanderfolgenden Sekto- 
ren (2048 Bytes) nur unwesentlich langsamer als das Lesen 
eines Sektors (512 Bytes). 

Wenn die Länge oder Dateiposition einer Anforderung 
kein Vielfaches von 512 Bytes ist, führt OS/2 nur die Zerle- 
gung unvollständig zu lesender Sektoren über die Puffer 
aus, Vollständig zu übertragende Sektoren werden direkt 
übergeben. Die Übertragung großer Datenmengen mit 
einer Operation ist auch dann sinnvoll, wenn die Sektoren- 
grenzen bei Anforderungen nicht berücksichtigt werden. 

Es läßt sich also feststellen, daß die Effizienz bei der 
Ein- und Ausgabe am größten ist, wenn umfangreiche 
Datenmengen angesprochen werden und die Datenanforde- 
rungen an den Sektorengrenzen ausgerichtet sind. Auch 
nicht ausgerichtete Datenanforderungen können mit einem 
guten Durchsatz ausgeführt werden, wenn umfangreiche 
Datenmengen in einer Operation bearbeitet werden. Bei 
Programmen, die keine dieser beiden Voraussetzungen 
erfüllen, empfiehlt sich die Verwendung der Routinen zum 
»Blocken« und »Entblocken«. Dies gilt auch bei umfangrei- 
chen Datenanforderungen, die nicht an Sektorengrenzen 
ausgerichtet sind. Programme mit häufigen kleinen Daten- 
anforderungen ohne Sektorenausrichtung arbeiten am 
besten, wenn Sektorenblöcke in interne Puffer gelesen und 
anschließend vom Programm selbst entblockt werden. Dies 
spart den Zeitbedarf für häufige DosRead- und DosWrite- 
Aufrufe. 

Gordon Letwin 


Der Text stammt aus dem Buch Buch »Inside OS/2« von 
Gordon Letwin, erschienen bei Microsoft Press. Die deutsche 
Übersetzung wird in Kürze im Vieweg-Verlag erscheinen, mit 
dessen freundlicher Genehmigung der Abdruck erfolgt. 
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Strukturierte Programmierung in BASIC am Beispiel: 
Terminalemulation mit QuickBASIC 


Der beste Weg, die überragenden Möglichkeiten 
von QuickBASIC zu demonstrieren, ist ein gutes 
Programmbeispiel. In diesem Artikel wird mit 
einem Terminalemulator ein solches Beispiel 
geliefert. 


Das Programm ADM3A.BAS, das in Listing 1 zu schen ist, 
ist ein einfaches Terminalemulationsprogramm. ADM3A 
macht aus einem PC oder Kompatiblen ein einfaches Bild- 
schirmterminal, in der Art des ADM3A von Lear Siegler. 
Ich habe gerade diese Terminalemulation gewählt, weil das 
ADM3A mit den meisten Unix- bzw. Xenix-Systemen und 
zahlreichen anderen Multiusersystemen verwendet werden 
kann. Der Emulator ermöglicht den Zugriff auf viele bild- 
schirmorientierte Programme, vom Editor VI bis zu kun- 
denspezifischen Datenbanken. 

Um den Emulator in der QuickBASIC-Umgebung zu 
starten, wird entweder der Start-Befehl im Menü ausge- 
wählt oder im Bearbeitungsmodus einfach [Shirt)(F5 
gedrückt. Bild 1 zeigt die Auswahl des Befehls Make EXE 
File, mit dem ein ausführbares Programm erzeugt wird, 
das von DOS aus gestartet werden kann. 




















Der Programmaufbau 


Das Programm ADM3A besteht aus einem einzigen Modul 

-mit einem halben Dutzend Unterprogrammen. Auf der 
Modulebene werden mit DECLARE SUB einige Unterrouti- 
nen definiert, damit der Compiler Anzahl und Typ der 
Parameter überprüfen kann, die an die jeweilige Unterrou- 
tine übergeben werden. Bild 2 zeigt die Modulliste von 
ADM3A unter QuickBASIC 4.0. In dieser Liste werden 
Module und Prozeduren innerhalb von Modulen aufgeführt. 
Auf diesem Bildschirm können Module und Prozeduren 
ausgewählt, verschoben und gelöscht werden. Der intelli- 
gente Editor erlaubt es normalerweise, jeweils eine Pro- 
grammeinheit zu bearbeiten. Man kann jedoch das Fenster 
mit dem View-Menü in zwei Teile aufteilen, um verschie- 
dene Teile eines Programms gleichzeitig zu sehen. 

Auf der Modulebene werden einige logische Konstanten 
als Werte, Farben und Tastencodes definiert. Wenn man 
ein BASIC-Programm liest und auf eine hart codierte 
Konstante wie zum Beispiel 3 stößt, hat man so gut wie 
überhaupt keine Information darüber, was dieser Wert 
bedeutet. Der Zusammenhang kann hilfreich sein. 


COLOR 3,1 
wirkt doch etwas schleierhaft, wenn man nicht weiß, was 
die Zahlen 3 und 1 hier bedeuten. Die Verwendung symbo- 
lischer Namen für konstante Werte ist wesentlich besser. So 
kann mit der Definition 
CONST BLACK = 8, BLUE = 1, .... „ CYAN = 5 
die COLOR-Anweisung wesentlich informativer und 
übersichtlicher geschrieben werden: 
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Bild 1: Die Oberfläche von QuickBASIC 4.0. 


COLOR CYAN, BLUE 


Besonders hinweisen möchte ich auch auf den 
»RECORD«-Datentyp WinType. Diese Fensterart verbin- 
det die Variablen für die Ecken eines Bildschirmfensters 
(oben, unten, rechts und links). Die Variablen CmdWin und 
Viewwin werden mit der DIM-Anweisung als Datentyp 
WinType deklariert. 

Die Zuweisungen, die auf die Variablendeklaration fol- 
gen, richten zwei Fensterbereiche auf dem Programmbild- 
schirm von ADM3A ein. Die oberste Bildschirmzeile ist das 
Befchlsfenster und der Rest des Bildschirms ist das Anzei- 
gefenster. Diese Aufteilung funktioniert sehr gut, da der 
Bildschirm eines ADM3A-Bildschirms 24 Zeilen mit 80 
Zeichen hat. Da die Befehlszeile oben auf dem Bildschirm 
plaziert wird, wird der Benutzer beim Wechsel zwischen der 
Betrachtung des Bildschirms und der Tastatur nicht von 
etwas anderem abgelenkt. Die Prozedur InitScreen 
kümmert sich um die Aufteilung des Bildschirms in Befehls- 
fenster und Anzeigefenster. Die Anweisung VIEW PRINT 
bewirkt, daß das Scrollen nur innerhalb des Anzeigefensters 
auftritt, wenn mit PRINT-Befehlen über die unterste Zeile 
hinaus geschrieben wird. Das Befehlsfenster ist in diesem 
Programm fest positioniert. 

Das Programm ADM3A verwendet eine optionale 
DOS-Umgebungsvariable für Einstellungen. Wenn in der 
DOS-Umgebung die Variable COMPARMS definiert ist, wird 
ihr Wert als Parameter in der Anweisung OPEN COM 
verwendet. Ansonsten verwendet ADM3A eingebaute 
Standardwerte. Es stellt dann die Werte, wie Adresse des 
Kommunikationsports und die BREAK-Signalmaske, die in 
der Prozedur BreakSignal verwendet wird, ein. 

Die Hauptschleife überwacht abwechselnd die Tastatur 
und den Puffer der Schnittstelle auf Eingaben. Aus der 
Sicht des lokalen Systems nimmt das Programm Eingaben 
von der Tastatur und schickt sie über die Schnittstelle an 
das entfernte System. Es liest ankommende Daten von der 
Schnittstelle und zeigt sie auf dem Bildschirm an. Dieses 
Grundmuster wird durch einige Sondercodes verändert. 






































% stended ‚code 
Fee ae Ne nere 


to see whether it is an Emulator 
U RSRSRL return to be callar wi e 


je Some uber 


" Clear the screen and "home" the cursor. 
‚COLOR WIITE, BLACK 














Bild 2: Die Modulliste von ADM3A .BAS. 


Wenn der Benutzer irgendetwas auf der Tastatur ein- 
gibt, wird es zum entfernten System geschickt, solange es 
sich dabei nicht um einen erweiterten Code handelt. Die 
drei ADM3A-Befehle Break, Dial und Quit werden 
durch erweiterte Codes aufgerufen, die aus Zwei-Byte- 
Codes bestehen, deren erstes Byte den Wert Null hat. 

Wenn INKEY$ einen erweiterten Code erhält, wird die- 
ser Code als Parameter dem Unterprogramm DoCommand 
übergeben, das den zweiten Code (den Scan-Code) unter- 
sucht und ihn mit einer Liste von Befehlscodes vergleicht. 
Bei den Tastenkombinationen (Alt)[E) und (Alt)[D) werden 
andere Prozeduren aufgerufen. Bei dem Befehl At)@) 
wird das Emulatorprogramm verlassen, nachdem die 
Schnittstelle geschlossen, der Bildschirm auf seine volle 
Größe und normale Attribute eingestellt und der Cursor in 
die Grundstellung positioniert worden ist. Der vierte 
Scancode, der von DoCommand erkannt wird, ist die Taste 
el). Bei einem Terminal schickt die Taste den 
ASCII-Code 127, der PC jedoch nicht. DoCommand wandelt 
den internen Code also in den vom entfernten System er- 
warteten um. 

Mit der Prozedur Dial wird eine einfache Möglichkeit 
zum Wählen geboten. Wenn der Benutzer (At)D) eingibt, 
antwortet das Programm mit der Eingabeaufforderung 
»Number:« im Anzeigefenster und wartet darauf, daß eine 
Telefonnummer eingegeben wird. Die Prozedur Dial ver- 
wendet dann diese Nummer, um mit dem String »ATDT« 
vor der Nummer ein Wähl-Kommando an das Modem zu 
schicken. (Es wird davon ausgegangen, daß Tonwahl bei 
einem Hayes-kompatiblen Modem verwendet wird.) 

Sobald die Verbindung mit dem entfernten System her- 
gestellt ist, muß der Benutzer sich einloggen und die Sit- 
zung so starten, wie es der Hostcomputer erwartet. Wäh- 
rend einer Sitzung kann es notwendig sein, dem Host mit- 
zuteilen, daß er mit dem aufhören soll, was er gerade tut. 
Dies wird im allgemeinen mit einer Break-Taste gemacht, 
wenn sie vorhanden ist. Unix- und Xenix-Systeme erkennen 
auch die [Del)-Taste als Unterbrechungstaste. 



























































Bild 3: ADM3A wird mit QuickBASIC 4.0 getestet. 


Die Prozedur BreakSignal, die von dem Kommando 
At] ®) aufgerufen wird, schickt ein echtes Break-Signal an 
den Host. BreakSignal arbeitet so, daß es das Break-Bit 
im Steuerregister der Schnittstelle setzt und es für eine 
Zeitspanne hochhält, die über die normale Zeitspanne für 
eine Zeichenübertragung hinausgeht; dann wird das Break- 
Bit wieder zurückgesetzt. 

Die Verzögerung, die hier auf eine halbe Sekunde ein- 
gestellt ist, wird von der Prozedur Delay erzeugt. Sie ver- 
wendet in einer Schleife die BASIC-Funktion TIMER, um 
die Zeit abzuwarten. Delay stellt die Startzeit fest, addiert 
die gewünschte Verzögerungszeit dazu und wartet dann, bis 
die durch die Summe angegebene Zeit erreicht wird. Um 
ein »Aufhängen« des Systems zu vermeiden, wenn die PC- 
Uhr um Mitternacht wieder auf Null zurückgesetzt wird, 
wird die Prozedur Delay abgebrochen, wenn der Zeitwert 
kleiner als die Startzeit ist. 

Die ankommenden Daten werden analysiert. Die mei- 
sten Zeichen werden einfach im Anzeigefenster auf dem 
PC-Bildschirm angezeigt. Einige der empfangenen Zei- 
chencodes haben jedoch eine spezielle Bedeutung: Steuer- 
codes, die eine absolute oder relative Cursorpositionierung 
bewirken oder den Bildschirm löschen. Das ADM3A ver- 
fügt nicht über Funktionen zum Einfügen oder Löschen von 
Zeilen/Zeichen, die Emulation ist also sehr einfach. 

Wenn der Code Escape festgestellt wird, könnte es sein, 
daß dadurch der Beginn eines Positionierungsbefehls 
signalisiert wird. Die Cursorposition wird mit Hilfe der 
Escapesequenz ESC=zs gesteuert, wobei z die Zeilennum- 
mer ist und c die Spaltennummer, die beide als ASCII- 
Werte codiert sind, so daß das Leerzeichen (Code 32) die 
Zeile bzw. Spalte 0 darstellt. Die Logik des Programms 
ADM3A entdeckt den Escapecode und wartet dann auf das 
Gleichheitszeichen. Wenn das folgende Zeichen eines ist, 
werden zwei weitere Zeichen gelesen und in die entspre- 
chenden Zeilen- und Spaltennummern relativ zum Anzei- 
gefenster (oben und links) umgewandelt und der Cursor 
entsprechend positioniert. 
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Bild 4: Ein Test von ADM3A. BAS mit VT unter Xenix. 


Wenn das nächste Zeichen kein »=« ist, druckt das Pro- 
gramm einfach das Escapezeichen und alles was folgt. 

Alle anderen Zeichen werden von der Prozedur Pro- 
cessInput untersucht, um festzustellen, ob sie angezeigt 
werden können. Einige Codes sind Steuerzeichen, Ctrl-Z 
löscht zum Beispiel den Bildschirm. Wie beim richtigen 
ADM3A-Terminal wird darauf geachtet, daß Grenzbedin- 
gungen erkannt werden. Bei einer Anforderung den Cursor 
nach rechts zu bewegen, wenn er bereits am rechten Rand 
des Fensters ist, wird beispielsweise die LOACTE-Anweisung 
verwendet, um den Cursor zum Anfang der nächsten Zeile 
zu bewegen, wenn eine vorhanden ist. 


Testhilfe durch QuickBASIC 


Das Debuggen und der Test des Programms wird durch die 
Debug-Möglichkeiten von QuickBASIC schr erleichtert. 
Bild 3 zeigt den Bildschirmaufbau, nachdem eine Watch- 
Ausdruck (CmdKey$) und ein Breakpoint auf der Anwei- 
sung SELECT CASE gesetzt wurden. Wenn das Programm 
dann gestartet wird, hält es bei dem Breakpoint an, so daß 
man den Wert des Watch-Ausdrucks untersuchen kann, Es 
können mehrere Watch-Ausdrücke und Breakpoints ver- 
wendet werden. Nach einem Breakpoint wird die Ausfüh- 
rung mit (F5) fortgesetzt. 

Die Beispielsitzung, die in Bild 4 zu schen ist, zeigt das 
Programm ADM3A, wie es auf ein Xenix-System zugreift. 
Es läuft der Editor VI und es wird gerade die Datei 
Jetc/termcap bearbeitet. Unter anderem ist der 
Termcap-Eintrag für das ADM3A-Terminal zu sehen, 
Jedes andere Programm, das weiß, wie ein ADM3A-Termi- 
nal angesteuert wird (was bei den meisten der Fall ist), 
kann mit dieser Emulation arbeiten. 


Eine Grundlage für erweiterte Emulationen 


Programme, die »schicke« Liniengrafikzeichen, reverse 
Darstellung und besondere Zeichenformatierungen ver- 
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wenden, sehen auf dem ADM3A-Terminal nicht sonderlich 
gut aus, einige laufen sogar vielleicht gar nicht. Sie können 
diese Emulation als Ausgangspunkt für ausgefeiltere Emu- 
lationen verwenden, zum Beispiel für ein VT100-Terminal. 
Sie werden wahrscheinlich auch Dateiübertragung und 
andere »intelligente« Terminalmöglichkeiten implementie- 
ren wollen, um dem Programm den letzten Schliff zu geben. 
Microsoft QuickBASIC bietet alle Voraussetzungen, die 
dafür nötig sind. 


QuickBASIC intern: 
Threaded-P-Code 


Microsoft QuickBASIC 4.0 ist sowohl ein Compiler als 
auch ein Interpreter. Der Compiler setzt ein Programm in 
einen Pseudocode um, der zu % Prozent aus Maschinen- 
code besteht. Dieser Code wird »Threaded P-Code« ge- 
nannt (verknüpfter Pseudocode). Der P-Code enthält genug 
Informationen, um den Quellcode jederzeit rekonstruieren 
zu können, so daß immer nur eine Version eines Pro- 
gramms im Speicher steht. 

Das ist sehr wichtig, da es jederzeit möglich sein soll, ein 
Programm ohne großen Übersetzungs- und Zeitaufwand zu 
starten, zu testen und zu bearbeiten. Und weil das Pro- 
gramm nur in einer Form im Speicher steht, und nicht als 
Quellcode, Objektmodul und ausführbares Programm, steht 
mehr Speicher für ein Programm zur Verfügung. 

Der Threaded-P-Code-Interpreter ist keine separate 
Programmeinheit, sondern ein verteilter Interpreter. Wenn 
eine BASIC-Zeile eingegeben wird, prüft QuickBASIC sie 
sofort auf Syntaxfehler. Wenn Fehler gefunden werden, 
müssen sie korrigiert werden, bevor eine Fortsetzung mög- 
lich ist. Wenn die Syntax in Ordnung ist, wird die Quellzeile 
in Threaded-P-Code umgesetzt, der aus einer Reihe von 
Ausführungsadressen besteht. Jede Ausführungsadresse ist 
einfach nur die Adresse einer Ausführungseinheit. 

Eine Ausführungseinheit ist eine Routine, die einen Teil 
der Arbeit einer BASIC-Anweisung übernimmt. Eine ein- 
zelne BASIC-Anweisung erzeugt in der Regel eine Reihe 
von Ausführungseinheiten, die miteinander verknüpft wer- 
den (»threaded«). Die Verknüpfung wird durch einen ver- 
teilten Interpreter erreicht, der aus zwei Maschinenbefehlen 
besteht, die vier Bytes lang sind und sieben CPU-Zyklen 
benötigen. Jede Ausführungseinheit sieht ungefähr so aus: 
Ausführungsroutine + LODSW ES + JMP AX 

Das ist alles. Ein Programm wird ausgeführt, indem ein- 
fach alle Ausführungseinheiten, die für eine bestimmte Auf- 
gabe benötigt werden, miteinander verknüpft werden. Es 
entsteht kein zusätzlicher Aufwand durch Routinenaufrufe 
(CALL/RET), ein Programm läuft also schr schnell - etwa 
so schnell, wie nicht optimierter Maschinencode. 

Ein Programm kann sich unter dem P-Code-Interpreter 
in drei Zuständen befinden: »geparst«, »symbolisch« und 





»verknüpft« (threaded). Ein P-Code-System mit nur zwei 
Zuständen, »geparst« und »verknüpft«, würde sehr langsam 
sein, da sich die Zeiten für die Umsetzung von geparstem 
Code in verknüpften P-Code aufsummiert. Durch die Ein- 
führung des symbolischen Zwischenzustands hat Microsoft 
sein Ziel der Möglichkeit für sofortige Programmänderun- 
gen erreicht. 

Der geparste Zustand ist das Ergebnis der Analyse der 
BASIC-Anweisungen, entweder von der Tastatur oder aus 
Dateien. Der größte Teil der Syntaxüberprüfung wird wäh- 
rend dieser Übersetzung erledigt. Die Teile eine Pro- 
gramms, die von Bearbeitungen der Anweisungen COMMON, 
SHARED oder DEF betroffen sind, werden in diesem Zu- 
stand gehalten. Die Umsetzung in Threaded-P-Code erfolgt 
auf einem PC-AT mit einem Durchsatz von 60000 Zeilen 
pro Minute, 

Der symbolische Zustand wird durch effiziente Symbol- 
tabellen-Informationen gekennzeichnet, die einen schnellen 
Datenzugriff ermöglicht. Die meisten Bearbeitungen, die 
keine globalen Änderungen erfordern, erfolgen in diesem 
Zustand. Nur die Teile eines Programm, die von den Ände- 
rungen berührt werden, müssen in diesen Zustand gebracht 
werden. 

Ein Programm läuft und wird getestet im verknüpften 
Zustand, in dem es sich die meiste Zeit befindet. Die Um- 
setzung vom symbolischen in den verknüpften Zustand 
macht es notwendig, Code zur Typenüberprüfung, Aufrufe 
von Bibliotheksfunktionen, Kontrollstrukturen und Label 
auf Speicheradressen einzufügen, sowie das Linken von 
COMMON-Daten und die Erzeugung der Adressen der P- 
Code-Ausführungseinheiten. 

Wenn nichtglobale Änderungen an einem Programm 
gemacht werden, werden nur die betroffenen Teile in den 
symbolischen Zustand zurückversetzt. Bevor das Programm 
wieder laufen kann, müssen die bearbeiteten Teile wieder in 
den verknüpften Zustand übersetzt werden. Diese 
»Rundreise« vom verknüpften in den symbolischen und 
zurück in den verknüpften Zustand erfolgt mit ungefähr 
150000 Zeilen pro Minute. Da man es meistens nur mit ein- 
zelnen Programmzeilen oder kleinen Programmteilen wie 
Funktionen und Unterroutinen zu tun hat, erfolgt die Um- 
setzung praktisch augenblicklich. 

Diese Technologie in QuickBASIC bietet viele Vorteile. 
Microsoft QuickBASIC weist den Weg in eine Ära erheb- 
lich verbesserter Programmiererproduktivität und bringt ein 
wenig Spaß in den ansonsten cher langweiligen Entwick- 
lungszyklus. 

Wie wird es weitergehen? Microsoft-Mitarbeiter haben 
öffentlich gesagt, daß ein großer Teil der Entwicklungs- 
arbeit für derzeitige und zukünftige Sprachprodukte in die 
P-Code-Technologie gesteckt wird, die die Grundlage für 
Compiler-Produkte anderer Sprachen und auch einige 
Anwendungsprogramme sein wird. Ich hoffe, daß diese 
Produkte schr bald angekündigt werden. 

Augie Hansen 











ADN3A Terminalemulator in QuickBASIC 4.8 
Version 1.8 


Dieses Programm emuliert das Terminal Lear Siegler ADH3A. 
Der Emulator erlaubt es PC-Benutzern, bildschirsorientierte 
Programme auf UNIX und XENIX-Systesen laufenzulassen. 


‚Autor: Augie Hansen 
Released: '1-14-88 


DEFINT A-Z 
De neo: 
eriodt) 


aan ae 
DECEARE SUB InitScreen () 
DECLARE SUB ProcessInput (Codes) 


Konstanten. 
OONST TRUE = -1, FALSE = NOT TRUE 
CONST BLACK = 8, BLUE = 1, GREEN = 2, CYAN = 3 


6, WHITE = 7 


Pre: en für Bildschirsverwaltung. 
Bi AS_INTEGER 

AS _INTEGER 
Hotton AS INTEGER 


(end AS INTEGER 
un Shandout AS INTECER 


DIM Cadkin AS WinType 
DIM Viewin AS WinType 


Gadhin.Top = 1 
Cadkin. 

Gdäin.Left = 1, 

Cadhin.Right = 

Gadhin.Fend | ao 
Cadhin.Bkgnd = WHITE 
Cadiin.Standout. = BROWN + BRICHT 


Vieslin.Top = 2 
Viewkin.Botton = 25 

Viewäin.Left = 1 

Viewäin.Right = BB 

Viewhin.Fgnd = WHITE 
Vieshin.Bkgnd = BLUE 
Viewlin.Standout = WHITE + BRIGHT 





--- Offsets für Be  unier ung: 
Rovöftset = SPACE - Viewdin.Top 
ColOffset = SPACE - Viewkin,.Left 


*--- Fehlerbehandlung installieren. 
ON ERROR GOTO ErrorRecovery 


'--- Esulatorbildschirs aufbauen. 
InitScreen 


JarzKonsunikationsparaneter einstellen. 
Para$ = ENVIRONS("COHP * Umgebung prüfen. 
IF Parns = "" THEN 

Parns = "OON2:12B8,E,7,1" 
END IF 


Port$ = LEFT$(Pars$, 4) 


* Standards verwenden. 
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IF Port$ = "COM1" THEN 
PortAddri 


'ess = SHSFB 
PortAddress = &H2FB 
END IF 
Breaklask = &H4B " Break-Steuerbits 
"--- Schnittstelle öffnen. 
’EN Parm$ FOR RANDOM AS #1 LEN = BUFSIZE 


D 
s Hauptschleife für Kommunikation. 


’ Tastatur abfragen. Alle normalen en Zeichen 

" zur Übertragung an das entfernte Sy: iber den 

" Kommunikationsport schicken. Wenn der Benutzer eine der 

Da Bauer tasten drückt, die entsprechende Routine 
aufrufen. 


Berne = FALSE 
EEE en auf Befehle und Zeichen untersuchen. 
Userkeys = 
IF Tenlüserkers) > 1 THEN 
ELSEIF UserKeys <> "” THEN 
'--- Zeichen an entferntes System schicken. 
nn A, Userkey$; 
Kor Schnittstelle auf empfangene Zeichen prüfen. 
IF EOF(1) THEN 
EXIT DO 
END IF 
Received$ = INPUTS(1, 71) ' Ein Zeichen lesen. 
Et EEE ENGEN ‚fen. 
Flag = TRUE THEN MS 
ee teceived$ = "=" THEN 
«ursorRow = ASC(INPUTS(1, #1)) - Rowöffset 
CursorCol = ASC(INPUTS(1, Hl - ColOffset 
LOCATE CursorRow, CursorCo] 


ELSE 
PRINT CHR$(27); " Escapecode erhalten. 
ze Received$: 


EscapeFlag = FALSE 
ProcessInput Receiveds 
et 








ErrorRecovery: 
RESUME Main 


! BreakSignal 
! Schickt ein Breaksignal an die Schnittstelle. 
SUB Brenksignat 

SHARED PortAddress, Breakliask 


'--- Breakbit setzen. 
OUT PortAddress, (INP(PortAddress) OR Breakllask) 


--- Verzögerung für Break. 
Delay «5 





Breakbit zurücksetzen. 
u u PortAddress, (INP(PortAddress) AND NOT BreakMask) 








Delay 


Bevirkt eine Verzögerung. Die Zeitspanne wird als Zahl mit 
einfacher Genaufgkeit in Sekunden und maximaler Genauigkeit 
von Zehntel: angegeben. 


SUB Delay (Period!) STATIC 
Start! = TIMER 


*'-—- Schleife für :ben Zeitspanne. 
Beenden, uhr Püberläuft B 


Nowt = TIMER 
IF (Now! - Start! < Periodt) OR (Now! < Start!) THEN 
EXIT SUB 


END IF 
LOOP 
END SUB 


Dial 
Benutzer nach Telefonnummer fragen und sie wählen. 


SUB Dial 
INPUT "Number: ”, Phones 
ut #1, "ATDT" + Phones 





" DoCommand 


' Den erweiterten Tastaturcode untersuchen, um festzustellen, 
" ob es ein Code für den Emulator ist. Wenn es das ist, den 
* geforderten Befehl ausführen. Wenn nicht, zurück zum auf- 
ı Fufenden Programm, ohne etwas zu machen. 


SUB DoCommand (Cadkeys) STATIC 
SHARED Cadhin AS WinType 
SELECT CASE ASC(RIGHTS(Cndkeys, 1)) 
CASE 16 ' Alt+q -- Quit: Emulator beenden. 
® Schnittstelle schliepen. 


* Ganzen Bildschira wiederherstellen. 

VIEM PRINT 

" Bildschirs löschen und Cursor in Grundposition. 
OOLOR WHITE, BLACK 


as 

LOCATE CadWin.Top, CadWin.Left, CURSORON 
CASE a: Alt+d — Dial: Numzer wählen 
CASE Ka * Alt+b -- Break: Breaksignal schicken. 


Pe 3 Be-Taste — ASCII DEL schicken. 
Kan: OHRS(127); 


* Unbekannte Befehle ignorieren. 
END SELECT 
END SUB 


" InitSereen 


" Befehlszeile aufbauen (1 Zeile), sicherstellen, dap der 
* Cursor an ist und das aktive Anzeigefenster des Terminals 
5 einrichten (24 Zeilen). 


SUB InitScreen STATIC 
SHARED CadWin AS WinType, Viewkin AS WinType 
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--- Bildschirm auf Text und 88 Spalten einstellen. 
SCREEN TEXTMODE 

NWIDTH COLS, ROWS 

‚COLOR HHITE, BLACK 

cLs 


'--- Befehlsfenster in oberster Zeile anzeigen. 
LOCATE OndWin.Top, CadWin.Left, CURSORON 

‚COLOR CadWin.Fgnd, CadWin.! a 

PRINT SPACES(CadWin.Right - Cadhin.Left + 1) 


*--- Programmnamen anzeigen. 
LOCATE CadMin.Top, Cadkin.Left + BANNERCOL 
COLOR CmdWin.Standout, CmdWin. Bkgnd 

PRINT "ADRSA EMULATOR"; 


»--- Befehle anzeigen. 
LOCKTE Gadhin.Top, Cnähin.Left. + COMANDOOL 


COLOR CadWin.F; 
PRINT "Break (Alt+b) “la Hu hTeeN Quit (Alt+g)" 


--- Terminalbildschirm anzeigen. 
vIEn PRINT ViewWin.Top TO ViewWin.Bottom 
2 Viewin.Fgnd, ViewWin.Bkgnd 


ao si 


rocessInput 


input von der Schnittstelle analysieren. Auf ADM3A-Befehle 
esgieren. Alles andere unverändert, in Änzeigefenster 
usgeben 














Reservierte Anwendungsnamen 


F: Wir haben eine Windows-Anwendung mit dem Namen 
DISPLAY.EXE Windows kann sie nicht aufrufen. Wenn wir 
die Datei auf so ziemlich jeden beliebigen anderen Namen 
umbenennen, kann die Anwendung gestartet werden. Haben 
wir gegen irgendwelche Regeln verstoßen oder einen reservier- 
ten Namen verwendet? Wenn ja, beschreiben Sie bitte alle 
diese Regeln. 


A: Sie haben einen Namen verwendet, der nicht für eine 
‚Anwendung verwendet werden darf. DISPLAY.EXE ist für 
die Hersteller von Bildschirmadaptern für die Erstellung 
von Gerätetreibern reserviert, damit sie diese testen kön- 
nen. Im folgenden werden einige weitere Namen aufgelistet, 
die Sie nicht verwenden dürfen: 





SPOOLER..EXE MOUSE .EXE 
CLIPBRD.EXE SYSTEM.EXE 
CONTROL .EXE WINOLDAP .EXE 
GDI.EXE KEYBOARD.EXE 
USER.EXE COMM.EXE 
KERNEL .EXE WIN. EXE 
MSDOS.EXE WINZAB.EXE 
MSDOSD.EXE 











a ET 
SE ASc(Eodes) Br 


SELECT CASE ASC(\ 
CASE 8 * ASCII Back: e-Zeichen 
IF POS(8) > Viewin.Left THEN 


" nichtdestruktives Backspace 
OR POS(8) - 1 


se 18 18 F. ”J -- Newline-Zeichen 
IF CSRLIN < ViewWin.Bottom THEN 
‚LOCATE CSRLIN + 1 
ELSE 
PRINT Codes; 
END IF 
CASE 11 * °K -- Zeile nach oben 
IF CSRLIN > ViewWin.Top THEN 
ae CSRLIN - 1 
se" 12 ! Fr -- Fornfeed-Zeichen 
” ADMSA verwendet ee Leerzeichen 
IF POS(8) < Viewkin.! > ll 
LOCATE_, POS(d) + 
ELSEIF (Pos(8) = ViewWin.Right) AND 
(CSRLIN < Viewkin.Bottom) THEN 


LOCATE CSRLIN + 1, Viewin.Left 
END IF 


CASE 13 
LOCATE „ Viewkin.Left 
CASE 26 ' 2 -- Bildschirm löschen 


cLs 
CASE 27 ” Esc -- ev. Beginn einer Escapesequenz 
= TRUE B IPRBRGU 


Esı Fl: 
CASE Fe Cursor in Grundposition 
a Viewin.Top, Viewin.Left 


PRINT Codes; 
END SELECT 
SUB 











Listing 1: Der Quellcode der ADM3A-Terminalemulation in 
QuickBASIC 4.0. 


Profi-Tools 
(e111773:7:K:][03 


Schreiben Sie schnellere, leistungsfähigere und 

Professionellere Programme! Wir helfen Ihnen 

dabei mit nützlichen Tools. 

Zum Beispiel: 

® Toolboxen (Fenstertechnik, Menüs, 
DOS-Funktionen etc.) 

® Relationale Datenbank mit komfortablem 
Masken-Editor 

© Grafik-Paket (Geschäftsgrafik und 
Zeichensatz-Generator) 

© Maus-Unterstützung für Ihre Programme 

Alle Pakete mit ausführlich dokumentierten 

Quelltexten und Programmbeispielen. Wo erfor- 

derlich, kommen schnelle Assembler-Routinen 

zum Einsatz. Wollen Sie mehr aus Ihrem BASIC- 

‚Compiler herausholen? Wir informieren Sie 

‚gerne kostenlos! 


Ingenieur-Büro Harald Zoschke 
Berliner Str. 3, D-2306 Schönberg/Holstein 


Telefon 04344/6166 
Eingetr Warenzeichen: QuickBASIC: Microsaf; 
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ragen & Antworten 


Herausfinden, wo sich 
Windows befindet 


F: Wie kann ich den Pfad des Win- 
dows-Verzeichnisses aus einer Anwen 
dung heraus feststellen? 





A: Verwenden Sie GetMod 
Name und } Im 
folgenden ein Beispiel dafür, wie man 
feststellen kann, von wo aus Windows 








geladen wurde: 


[define PATHNAX 88 
char szTenp[PATHMAX+1]; 


GetModuleFileName 
( GetModuleHandle((LPSTR)"kernel"), 
szTemp, PATHMAX ); 


/" szTenp enthält nun Laufverk und Pfad 
von/aus dem Windows geladen wurde #/ 


Ein Fenster durch ein 
anderes ersetzen 


F: Der MS-DOS Executive kann ein 
Fenster durch ein anderes ersetzen, wie 
macht er das? 


A: Wenn das höherwertige Byte des 
Flag-Wortes, bei ShowWindows ( != 
0xFF ) ist, wird es mit dem anfordern- 
den Fenster ausgetauscht. Verwenden 
Sie diese Möglichkeit auf eigene Ver- 
antwortung, die Schnittstelle kann 
jederzeit ohne spezielle Mitteilung 
geändert werden. 
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ECHT SCHNELL DAGEGEN: 
MICROSOFT QUICKBASIC 4.0. 





Ein Compiler, so 
schnell, daß Sie 








Eine Schnecke bleibt eine Schnecke - auch 
wenn sie sich durch allerlei Mimikry - Spoi- 
ler, wohlklingende Namen und ähnliches — 
ein rasantes Outfit schneidert. 

Werfen Sie dagegen bei der neuen deutschen 
Version von Microsoft QuickBASIC 4.0 
mal einen Blick unter die Haube: Da 
gibt es statt Show-Tuning einen völlig 
em neu überarbeiteten Compiler. So sensa- 


wie mit 

Ana ei- tionell schnell, daß Sie damit wie mit 
ten. Integrierte 

Entwicklungsum- EINEM Interpreter arbeiten können: 


gebung: Compi- Programm ausführen, anhalten zum 
ler, Editor und Debuggen und Verändern, einfach wei- 


Debugger in 
Syntax- 


einem. 


terlaufen lassen — ohne lästige Warte- 


überprüfung hei Zeit. Programmänderungen baut Micro- 
der Eingabe und soft QuickBASIC 4.0 um die 150.000 


kontextsensitive 


Hilfe, 


Zeilen pro Minute ein - eine echte 
Revolution! Revolutionär auch die 
automatische Syntaxüberprüfung direkt 
beim Eintippen des Programmcodes. Fehler 
werden sofort angezeigt - die integriere 
Hilfefunktion liefert dazu schnellstens 
‚Antworten. 

Und hier das absolut neue Fahrgefühl: Auf- 
rufe der Microsoft Sprachen C 5.0, QuickC, 
FORTRAN 4.0, Makroassembler und 
PASCAL 4.0 werden ebenso unterstützt wie 
die Herkules Graphikkarte und die Intel 
8087/80287 Koprozessoren. 

Also umsteigen, bei uns einsteigen und ab 
geht die Post. Eine Probefahrt wird Sie rest- 
los überzeugen. 


Ms/nos) (me) [320/1m) 3:754 








Microsoft 


ZUKUNFT DER SOFTWARE 


couroNn 


Bitte senden Sie mir Informationsmaterial zu Microsoft QuickBASIC 4.0. 
DO beruflich/Branche 


Ich nutze Software: U] privat 
Mein Rechner: U] MS-D05 


DIMS.05/2 


D Macintosh 


Bitte senden Sie den Coupon an: Microsoft GmbH - Erdinger Landstraße 2 - 8011 Aschheim-Dornach 


Absender nicht vergessen. 





la) 


Die TextOut-Funktion 
beschleunigen 


F: Gibt es eine Möglichkeit, die Funk- 
tion TextOut von Windows zu be- 
schleunigen? 


A: Ja, um die Geschwindigkeit der 
Funktion TextOut zu beschleunigen, 
verwenden Sie folgende Methode: 


1. Berechnen Sie die obere linke 
Ecke der ersten Zeichenzelle von 
TextOut in Client-Koordinaten. 

2. Wandeln Sie die Client-Koordina- 
ten in Bildschirmkoordinaten um 
(ClientToScreen, physische 
Einheiten). 

3. Richten Sie die Bildschirmkoordi- 
naten mit Moduloarithmetik auf 
eine 8-Bit-Grenze aus (/ oder %). 
Der Bildschirm wird Zeile für 
Zeile verwaltet und ist auf Worte 
ausgerichtet. Durch die Ausrich- 
tung auf die Bytegrenze wird die 
Rotierung von Bits bei Textout 
vermieden. 

4. Wandeln Sie die ausgerichteten 
Bildschirmkoordinaten in Client- 
Koordinaten zurück. 


Ein Piepser unter Windows 


F: Was ist die einfachste Methode, 
unter Windows einen Piepser zu erzeu- 
gen (wie bei MessageBeep, jedoch ohne 
Meldungsbox)? 


A: Verwenden Sie MessageBeep( ) 
mit jeder beliebigen Konstante außer 
denen, die in WINDOWS.H. definiert 
sind. Die Konstante ist die relative 
Dauer des Piepsers. Es wird keine 
Meldungsbox angezeigt. Diese Mög- 
lichkeit ist nicht dokumentiert. 
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Termine 


Termine ... Termine . 


Mit Microsoft-Seminaren sicher in die Zukunft 


Das Betriebssystem der Zukunft heißt Microsoft OS/2. 
Microsoft Windows und der Presentation Manager sind 
bzw. werden die Benutzeroberflächen der Zukunft sein. Für 
professionelle Entwickler bedeutet das, sich ab sofort mit 
dieser neuen Software auseinandersetzen zu müssen. Damit 
schaffen sie die Voraussetzung, schnellstmöglich Program- 
me in der »neuen Welt« verfügbar zu haben. 

Natürlich wird die Umstellung auf das neue Betriebs- 
system sowie die Programmerstellung nicht von heute auf 
morgen vollzogen sein. Um den Anfang jedoch so einfach 
wie möglich zu gestalten, bietet Microsoft eine neue Dienst- 
leistung an: Das Microsoft Institut. 

Die Spezialseminare des Microsoft Instituts vermitteln 
in kleinen Gruppen intensiv all das, was zum Einstieg in die 
Programmentwicklung nötig ist. Modernste Trainings- 
methoden sowie PC-Demonstrationen und -Übungen sind 
selbstverständlich. Die Dozenten befassen sich auch im per- 
sönlichen Gespräch ausführlich mit den individuellen For- 
derungen und Problemen der Teilnehmer. So bekommen 
professionelle Entwickler durch professionelle Schulung die 
Möglichkeit, ihren hohen Wissenstand den neuen Gegeben- 
heiten anzupassen. 

Jeder Interessent in der Bundesrepublik Deutschland, 
der Schweiz und Österreich hat die Chance, sich mit der 
neuen Welt von Microsoft OS/2 und Microsoft Windows 
auseinanderzusetzen. Denn das Microsoft Institut arbeitet 
vor Ort mit kompetenten Schulungsunternehmen zusam- 
men: 

Digicomp AG, Zürich 

Elektro-Calcul PI S.A., Lausanne 

Integrata GmbH, Tübingen 

INTEL Semiconductor GmbH, München 

Olivetti Bildungs-Zentrum GmbH, Düsseldorf 

Ueberreuter Media GmbH, Wien. 

Die Dozenten werden speziell von Microsoft ausgebildet 
und stehen in ständigem Kontakt mit uns. So gibt es keine 
Informationsverluste: Das Wissen wird immer aktuell und 
aus erster Hand vermittelt. Microsoft erstellt die Seminare 
und die Seminarunterlagen und gewährleistet Qualität 
durch die Auswertung der Seminare. 


Das Microsoft OS/2 Einführungs-Seminar 


Das zweitägige Seminar wendet sich an PC-Software-Ent- 
wickler, die Programmierkenntnisse in einer höheren Pro- 
grammiersprache wie C, Pascal, o.ä. besitzen. 

Die Teilnehmer lernen im Vortrag und in Diskussionen 
das Konzept von Microsoft OS/2 kennen und erhalten 
einen Überblick über die Fähigkeiten und Programmier- 
schnittstellen dieses Betriebssystems. Während des 
Seminars haben die Teilnehmer die Möglichkeit, das 
Gelernte anhand von Übungsaufgaben für sich selbst zu 
überprüfen. 


64 Microsoft System Journal Juli/August 1988 


.. Termine ... Termine 








Ort Datum Veranstalter 
Düsseldorf 04./05.07. OBZ 
01./02.08. OBZ 
05./06.09. OBZ 
Frankfurt 21./22.07. Integrata 
05./06.09. Integrata 
Hamburg 07./08.07. Integrata 
08./09.08. Integrata 
München 11./12.07. Intel 
18./19.07. Integrata 
18./19.07. OBZ 
01./02.08. Integrata 
22./33.08. OBZ 
29./30.08. Integrata 
12./13.9. Intel 
15./16.9. Integrata 
Münster 19./20.09. Integrata 
Tübingen 04./05.07. Integrata 
25./26.07. Integrata 
22./23.08. Integrata 
26./27.9. Integrata 
Graz 15./16.9. Ueberreuter 
Innsbruck 19./20.9. Ueberreuter 
Wien 11./12.07. Ueberreuter 
29./30.08. Ueberreuter 
15./16.09. Ueberreuter 
19./20.09. Ueberreuter 
Genf 14./15.09. Electro Calcul 
Zürich 07./08.07. Digicomp 
22./23.08. Digicomp 
21./22.09. Digicomp 
Der Microsoft OS/2 Workshop 


Das dreitägige Seminar wendet sich an PC-Software-Ent- 
wickler, die Programmiererfahrungen in einer höheren, 
strukturierten Programmiersprache unter MS-DOS und C- 
Kenntnisse besitzen sowie das MS-OS/2-Einführungssemi- 
nar besucht haben. 

Die Teilnehmer lernen im Vortrag und praktischen 
Übungen am PC Family-API-Programme zu schreiben und 
Device-I/O-Routinen zu erstellen sowie Multitasking-Funk- 
tionen zu nutzen und eigene Dynamic-Link-Bibliotheken zu 
erstellen; außerdem können sie die erweiterten Speicherver- 
waltungsmöglichkeiten des Intel 80286 nutzen und mit Hilfe 
des MS-OS/2 Memory Managers programmieren. Dieses 
Seminar ist übrigens nicht im SDK-Preis enthalten. 


ermine 





. 
Termine 
Ort Datum Veranstalter 
Düsseldorf 06./07./08.07. OBZ 
03./04./05.08. OBZ 
07./08./09.9.  OBZ 
Frankfurt 07./08./09.09. Integrata 
Hamburg 10./11./12.08. Integrata 
München 13./14./15.07. Intel 
20./21./22.07. OBZ 
03./04./05.08. Integrata 
31./01./02.09. Integrata 
14./15./16.09. Intel 
21./22./23.09. OBZ 
Münster 21./22./23.09. Integrata 
Tübingen 27./28./29.07. Integrata 
28./29./30.09. Integrata 
Genf 26./27./28.09. Electro Calcul 
Wien 05./06./07.09. Ueberreuter 
Zürich 13./14./15.07. _ Digicomp 
29./30./31.08. Digicomp 








Das Microsoft Windows Einführungs-Seminar 


Das zweitägige Seminar wendet sich an PC-Software-Ent- 
wickler, die Programmierkenntnisse in einer höheren Pro- 
grammiersprache wie C, Pascal, o.ä. besitzen. 

Die Teilnehmer lernen im Vortrag und in Diskussionen 


... Termine ... Termine ... Termine 


Der Microsoft Windows Workshop 


Das dreitägige Seminar wendet sich an PC-Software-Ent- 
wickler, die Programmiererfahrungen in einer höheren, 
strukturierten Programmiersprache unter MS-DOS und C- 
Kenntnisse besitzen sowie das Microsoft Windows Einfüh- 
rungsseminar besucht haben. 

Die Teilnehmer lernen im Vortrag und praktischen 
Übungen am PC Benutzerschnittstellen zu erstellen, die 
grafische Programmierschnittstelle zu nutzen, die Routinen 
zum Memory Management anzuwenden und dynamische 
Bibliotheken zu erstellen und zu benutzen. Dieses Seminar 


ist nicht im SDK-Preis enthalten. 
Ort Datum Veranstalter 
Düsseldorf 13./14./15.07.  OBZ 


17./18./19.8.  OBZ 
14./15./16.9.  OBZ 


Frankfurt 24./25./26.08. Integrata 
Hamburg 14./15./16.09. Integrata 
München 27./28./29.07. Integrata 


27./28./29.07. Intel 
17./18./19.08. Integrata 


das Konzept von Microsoft Windows kennen und erhalten 
einen Überblick über dessen Fähigkeiten und Program- 
mierschnittstellen. Dieses Seminar ist nicht im SDK-Preis 


Münster 10./11./12.08. Integrata 
Tübingen 21./22./23.9. Integrata 
Wien 24./25./26.08. Ueberreuter 
Zürich 10./11./12.08. Digicomp 
26./27./28.09. Digicomp 


enthalten. 





Ort Datum Veranstalter 
Düsseldorf 11./12.07. OBZ 
15./16.08. OBZ 
12./13.09. OBZ 
Frankfurt 01./02.08. Integrata 
22./23.08. Integrata 
Hamburg 11./12.07 Integrata 
12./13.9. Integrata 
München 18./19.07. Integrata 
25./26.07. Intel 
25./26.07. Integrata 
01./02.9. Integrata 
26./27.09. Integrata 
Münster 08./09.08. Integrata 
Tübingen 07./08.07. Integrata 
15./16.08. Integrata 
29./30.08. Integrata 
19./20.09. Integrata 
Graz 26./27.09. Ueberreuter 
Innsbruck 05./06.09. Ueberreuter 
Wien 22./23.08. Ueberreuter 
Zürich 11./12.08. Digicomp 
21./22.9. Digicomp 


Microsoft Excel für Programmierer 


Das dreitägige Seminar wendet sich an PC-Software- 
Entwickler, die Programmiererfahrung in einer höheren 
Programmiersprache haben. 

Die Teilnehmer lernen im Vortrag und in praktischen 
Übungen am PC das Konzept und die Möglichkeiten, mit 
Microsoft Excel-Makros Applikationen zu erstellen. 


Ort Datum Veranstalter 


Düsseldorf 18./19./20.07. _OBZ 
08./09./10.08.  OBZ 
19./20./21.09.  OBZ 


Hamburg 10./11./12.08. Integrata 
Tübingen 13./14./15.07. Integrata 
Baden 12./13./14.09. Integrata 
Wien 16./17./18.08. Ueberreuter 
12./13./14.09. Ueberreuter 
Neuchatel 29./30./31.08. Electro Calcul 
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Microsoft C und \& 


Tips zur C-Programmierung: 


Dynamische Speicherverwaltungstechniken 


Die meisten Anwender besitzen zwischen 64 und 
640 Kilobyte Arbeitsspeicher in Ihren PCs, und 
es kann fast davon ausgegangen werden, daß 
viele ihre Computer noch mit Zusatzspeicher 
erweitert haben. Obwohl wir die Ober- und die 
Untergrenzen der Speicherausbauten kennen, 
können wir nie ganz sicher sein, wieviel Speicher 
der einzelne Computer besitzt. 


Programme können geschrieben werden, um in einer fest 
definierten Umgebung zu laufen, oder sie können sich dy- 
namisch an den verfügbaren Speicher angleichen. Pro- 
gramme, die eine flexible Speicherverwaltung unterstützen, 
sind besonders nützlich. Ich merkte dies, als meine Lieb- 
lingstextverarbeitung die gerade zusätzlich installierten 128 
Kbyte Arbeitsspeicher nicht nutzen konnte. Stattdessen griff 
sie weiter ständig auf das Diskettenlaufwerk des PCs zu. 

Hätten die Programmierer, die mein Textverarbeitungs- 
system geschrieben haben, von dynamischer Speicherver- 
waltung Gebrauch gemacht, könnte das Programm den 
zusätzlichen Speicher für größere Textteile oder sogar für 
einen größeren Teil des Programms selbst verwenden. 

Dynamisches Allokieren erlaubt es Programmen, sich 
selbst an die Umgebung anzupassen und damit die Vorteile 
des verfügbaren Speichers zu nutzen. Solche Programme 
allokieren Speicher dynamisch, um Arrays und verkettete 
Listen zu verwalten, anstatt feste Arraygrößen zu verwen- 
den, die der Programmierer bei der Deklaration festlegen 
muß. Die einzige Grenze der Arraygröße ist der verfügbare 
Speicher auf dem System des Anwenders. 

Dieser Artikel erläutert den Einsatz der C-Standard- 
funktionen, um Programme zu schreiben, die Datenstruktu- 
ren verwenden, die dynamisch wachsen und kleiner werden, 
während das Programm läuft. Wir implementieren Funktio- 
nen für Arrays und verkettete Listen, die für dynamische 
Speicherverwaltung besonders gut geeignet sind. 

Die Standardfunktionen malloc und free gehören zu 
den Werkzeugen, die hier erläutert werden. Die Funktion 
malloc erwartet als Argument die Anzahl der zu allokie- 
renden Byte und gibt als Ergebnis einen Zeiger auf den 
Anfang des Speicherblocks zurück, vorausgesetzt, es ist 
noch genügend Speicher vorhanden. Ein Aufruf der Funk- 
tion free gibt den dynamisch allokierten Speicher an den 
Pool des verfügbaren Speichers zurück. 





Das Problem 


Wie die meisten Programmiersprachen, so verlangt auch C, 
daß Sie bei der Deklaration eines Arrays seine Größe fest- 
legen. Dies erweist sich häufig als Einschränkung für ein 
Programm, da eine Obergrenze für die Menge der zu bear- 
beitenden Daten gesetzt wird. Wieso nicht das Array so 
groß machen, daß die größtmögliche Datenmenge bear- 
beitet werden kann? 
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a) 
short zaehler; /" 2 Byte Speicher */ 
static char namen. _liste[1800)[25] = {\9'}; 
int status_vektor[18]; n a Byte bei 16 Bit CPU ®/ 
8 Byte vis 32 Bit CPU */ 
printf( 


'sizeof zaehler %d, nanen_liste %d, status_vektor £d\n”, 
sizeof zaehler, sizeof nanen_liste, 
sizeof status. ; Vektor); 


printf("int's sind %d Bytes, Ich bin eine %d Bit-CPU\n", 
sizeof(int), 8 * sizeof(int)); 





Die Ausgabe des obigen Programms: 





sizeof zaehler 2, namen liste 25888, status_vektor 28 
int's sind 2 Bytes, Ich bin eine 16 Bit-CPU” 











Listing 1: Die Verwendung von sizeof zur Feststellung des 
Speicherbedarfs. 


Unglücklicherweise ist der Speicher nicht grenzenlos. Je 
mehr Speicher ein Programm benötigt, um so größer muß 
das System sein, auf dem das Programm läuft. Da die TSR- 
Programme (Hintergrundprogramme) beliebter werden, 
und der Platzbedarf des Betriebssystems wächst, wird es 
immer sinnvoller, daß die Programme nur so viel Speicher 
belegen, wie sie benötigen. Der Speicher eines PCs ist zu 
einer gemeinsam benutzten Ressource geworden. Welche 
Möglichkeit hat nun ein Programmierer, den Speicher für 
die Daten zu reservieren? 


Speicherorganisation 


Der Speicher eines Programms ist in Bereiche unterteilt, 
die Heap, Stack, Daten und Code genannt werden. Der 
Heap liegt am oberen Ende des Speicherbereichs eines 
Programms und ist die Quelle für dynamisch allokierten 
Speicher. Die Größe des Heaps hängt von der Größe der 
anderen Bereiche ab, da seine Größe dem verfügbaren 
Speicher, der nicht von anderen Bereichen belegt wird, ent- 
spricht. 

Der Stack liegt unterhalb des Heaps im Speicher. Seine 
Größe stellt der Linker ein, entweder voreingestellt 2048 
Bytes, oder die Größe, die dem Linker mit der Option 
/STACK angegeben wird. Der Datenbereich enthält stati- 
sche und externe Variablen. Die Programmbefehle sind im 
Codebereich angesiedelt. 


Allokieren von Speicher 


Verfügt ein Programm über Speicher für seine ausschließ- 
liche Verwendung, sagt man, der Speicher ist von diesem 
Programm allokiert. C-Programme bieten zwei Möglich- 


Microsoft C und Qi 








(% 
* SUM_NUM.C: Eiı und Aufsummierung einer variablen Anzahl 
yon "Integern. Zeigt Liste der Zahlen und die Aufsummierung. 
PaLBR) 
long *zahlen; /* Zeiger auf das Zahlenarray */ 
short anzahl ; /* Anzahl der elı 





/#* Index in das Zah) En n = 
x in 
/* Summe der Zahlen Bee sw 


rintf("Wie viele Zahlen sumaieren? "); 
‚(1 te scanf("Ahd", anzahl) I1 ae 2 2) 
exit(1); Programaende *, 


/% Dynamisches Allokieren von anzahl ar, Ss“ 
zahlen = (long *) calloc(anzahl, sizeof(long)); 


for(ind zahl = 8; ind zahl < anzahl; ++ind zahl) { 


/® Zahleneingabe #/° 
Por Rd: 


„ ind_zahl + 1); 
to seanecAldr, Kzahlentind zn), 
anzahl = ind zahl; '* Abbruch 


x (sunme = ind_ zahl = 9; a en ++ind_zahl) { 
sunge +- zahlenlind zahl]; ”/* Zahl zur Summe addieren »/ 
a ad EHEN /n ee anzeigen */ 

ind_zahl + 1, zahlenl ind, | zahl], sumne); 


} 
printf("\nDie Sunne der $d eingegebenen Zahlen ist Kld\n", 
anzahl, sunme); 














Listing 2: Das Programm SUM_NUM.C. 


keiten der Speicherallokierung. Der gebräuchlichste Weg ist 
die einfache Deklaration von Variablen. Der andere Weg ist 
das dynamische Allokieren durch den Aufruf von Stan- 
dardfunktionen, wie malloc, calloc und realloc. 

Der Speicher für statische und externe Variablen wird 
nur einmal vor der Programmausführung allokiert und 
initialisiert, nämlich beim Laden von der Diskette in den 
Arbeitsspeicher. Er bleibt allokiert, bis das Programm 
endet. 

Alle anderen Variablen, die mit der Speicherklasse 
auto und register, werden bei jedem Eintritt in die 
Funktion (Block), in der sie deklariert sind, allokiert. Der 
Speicher für auto- und register-Variablen wird beim 
Verlassen der Funktion (Block) wieder freigegeben 
(deallokiert). 

Da der Speicher für die statischen und die externen 
Variablen während der gesamten Laufzeit benötigt wird, 
spart das Vermindern dieser Variablen RAM. Auto- und 
register-Variablen hingegen werden nur allokiert, wäh- 
rend die Funktion aktiv ist (auf dem Stack). Eine Funktion 
ist aktiv, wenn sie von main oder einer anderen Funktion 
aufgerufen wird. Lebensdauer, Gültigkeit und Initialisierung 
sind andere Faktoren, wenn Sie Speicherklassen für Ihre 
Variablen auswählen. 

Zum dynamischen Allokieren muß die Größe des benö- 
tigten Speichers bekannt sein. Das C-Schlüsselwort sizeof 
wird verwendet, um die Anzahl der Bytes der verwendeten 
Variablen zu finden. Der Operator sizeof muß auch für 


end, 
1 tee, I Gewöhnliches long-Array 
Re En Zeiger auf A long &/ 


Rt = &long arraylB]; ya Zeiger auf den Beginn des #/ 
In Arrays allein “7 


ge gleich uam, P onelel, Img iong erresfell; 
BESTER p_longs %d, sIzeo! 
sizeof p_longs, Sizeof ent 





Die Ausgabe: 





32 gleich 32 
sizeof p_longs 2, sizeof long array 408 








Listing 3: Die Verwendung von Zeigern mit Arrays. 


in Klammern eingeschlossene Datentypen verwendet wer- 
den. Das bedeutet, daß das Programm den Wert des Aus- 
drucks sizeof(int) mit zwei oder vier berechnen kann, 
abhängig von der Übersetzung auf einer 16- oder 32-Bit- 
CPU (Listing I). 


Arrays variabler Länge 


Die dynamische Allokierung eines Speicherblocks findet zur 
Laufzeit des Programms statt. Die Größe wird durch Funk- 
tionsargumente beim Aufruf der Standardfunktionen, wie 
malloc, calloc oder realloc, festgelegt. Dies ist unter- 
schiedlich zur Deklaration eines Arrays, die an eine Kon- 
stante oder an einen Konstantenausdruck gebunden ist. 

Das Grundprogramm SUM_NUM in Listing 2 verwendet 
die Standardfunktion calloc. In SUM_NUM gibt calloc 
die Startadresse des Speicherblocks zurück, dessen Größe 
durch die Übergabe der Funktionsargumente Anzahl und 
Größe der Elemente festgelegt ist. Sie brauchen nur einen 
Zeiger auf den Datentyp, der gespeichert werden soll dekla- 
rieren und das Funktionsergebnis diesem zuweisen wie im 
folgenden gezeigt: 





long *zahlen 


zahlen = (long *) calloc(anzahl, sizeof(long)); 











Diese zwei Statements erzeugen ein dynamisch allo- 
kiertes Array von anzahl long-Integerzahlen, und initiali- 
sieren den Zeiger zahlen auf das Array. 

Das (long *) vor calloc, welches ein cast-Opera- 
tor ist, drückt Zeiger auf den Datentyp long aus, und ist 
optional. Es ist eine Typumwandlung, die Compilerwarnun- 
gen wie »different levels of indirection« vermeidet. 
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46 11-18-8663: 
7: 


NEMO TXT 
DIROUT TAT 1286 1-17-87 





Listing 4: Beispieldaten von einem DIR-Befehl. 


Wird eine Funktion nicht vor der Verwendung dekla- 
riert, oder wird ihr Rückkehrtyp nicht explizit (wie zum Bei- 
spiel long) deklariert, nimmt der Compiler an, daß die 
Funktion ein int-Ergebnis liefert. Die Zuweisung des 
Funktionsergebnisses von calloc ohne (long *) an 
zahlen hätte als Ergebnis die Zuweisung einer int-Zahl 
an eine Variable, die als Zeiger auf long deklariert ist. 
Dies veranlaßt den Compiler eine Warnung auszugeben. 

Ist der angeforderte Speicher nicht mehr verfügbar, lie- 
fert calloc den Wert NULL, der in stdio.h als ® defi- 
niert ist. Prüfen Sie etwa den Funktionsaufruf nicht auf den 
speziellen Rückgabewert 0, und speichern Daten an dieser 
Adresse, erhalten Sie am Programmende die Fehlermel- 
dung »null pointer assignment«. Das Schreiben von Daten 
in nicht allokierten Speicher kann leicht unbemerkt bleiben 
und schwer zu findende Fehler verursachen. Schwer zu fin- 
den deshalb, weil das Programm nur in einigen Fällen ver- 
sagen kann, die bei der Programmerstellung eventuell nicht 
berücksichtigt wurden. 


Zeiger und Arrays 


Das Verständnis von Zeigern und Arrays ist schr wichtig in 
C, speziell bei der Speicherverwaltung. Zeiger- und Array- 
Datentypen sind schr ähnlich - vielleicht mehr, als Sie glau- 
ben. Immer wenn Sie in einem Ausdruck ein Array verwen- 
den, etwa bei der Parameterübergabe zu einer Funktion 
oder beim Erhalten des Wertes eines Elements, wird die 
Startadresse des Arrays verwendet. Wenn Sie eine Zeiger- 
variable verwenden, die auf ein Array desselben Datentyps 
zeigt, so können Sie den Zeiger in Ausdrücken verwenden, 
als wäre er das Array (Listing 3). 

Die Tatsache, daß sich Zeiger ähnlich wie Arrays ver- 
halten, bedeutet, daß Sie Elemente des Arrays mit der Vari- 
ablen zahlen bearbeiten können (Listing 2), so als ob 
zahlen ein Array von long-Integern wäre. Die Adresse 
eines Elements, auf die zahlen im Ausdruck &zahlen 
[anzahl] zeigt wird der Funktion scanf übergeben. Der 
Wert des Elements wird zur Summe im Statement summe 
+= zahlen[anzahl]; addiert. 

Selbst wenn Sie ein C-Neuling sind, werden Sie damit 
jedesmal konfrontiert, wenn Sie eine Funktion programmie- 
ren, die mit Arrayelementen arbeitet, die als Parameter 
übergeben werden. Die Parameter einer Funktion, die 
Daten eines Arrays erhalten, werden mit leeren eckigen 
Klammern deklariert, wie im Ausdruck get_param[]. C 
übergibt an diese Funktion die Startadresse des Arrays. 
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Zinclude <stdio.. /* Für NULL-Zeiger Definition #/ 
define DIR, a LEN 39 /® Zeilenlänge von DIR #/ 
struct s_dir_node { 


strüct 5_dir_node #next; /* Zeiger auf nächsten Knoten #/ 
7® oder NULL #/ 
eher, ir. 1nefDIR LINE. LEN + 13; /# DIR Ausgabezeile »/ 


s_dir_node *p_head; /* Zeiger zum Listenbeginn #/ 
1; /# Zeil 
/* Lis! 


r zu neuem Eli ” 
ist leer / 














Listing 5: Deklaration der Kennung der Verbindungsstruktur. 


Die Funktion behandelt den Parameter als Array, 
obwohl der Parameter eigentlich ein Zeiger ist. Der einzige 
Unterschied zwischen Zeigern und Arrays besteht bei der 
Verwendung des sizeof-Operators. Im Listing 3 gibt der 
sizeof-Operator unterschiedliche Werte für p_long und 
long_array zurück. 

Die Konsequenz dieser Art der Paramterübergabe ist, 
daß die aufgerufene Funktion nicht die Dimension eines an 
sie übergebenen Arrays kennt. Da das Array für sie nicht 
verfügbar ist, kann sie die Größe nicht testen. Stattdessen 
ist der übergebene Wert ein Zeiger auf das erste Element, 
und eine Zeigervariable ist 2 oder 4 Bytes lang (int oder 
long auf einer 16-Bit-Maschine): 


Rückgabe des Speichers 


Beim Programmende wird der ganze allokierte Speicher 
zurückgegeben. Dies beinhaltet auch den von Funktionen 
wie calloc allokierten dynamischen Speicher. Wird allo- 
kierter Speicher deallokiert, so steht er für weitere Spei- 
cheranforderungen zur Verfügung. Benötigt Ihr Programm 
mehrere Allokierungen, so können Sie die Funktion free 
aufrufen, um nicht zu wenig Speicher zur Verfügung zu 
haben. Rufen Sie free auf, um nicht mehr benötigte 
Speicherblöcke zurückzugeben. Die Funktion free benö- 
tigt als Argument dieselbe Adresse, die ein früherer Funkti- 
onsaufruf von calloc, malloc oder realloc als Ergeb- 
nis lieferte, wie zum Beispiel; 





zahlen = Kong *)calloc(anzahl, sizeof(long)); 
free(zahlen: 
I Deallokiert Speicher, auf den zahlen zeigt */ 














ckC 








/% Dynamisches Allokieren und zuweisen der Daten #/ 
p_new = (struct s dir node *) 
malloc(sTzeof(struct s_dir_node)); 


y{p_nev->dir line, 
TR 1206. 22.05.88 12.28”); 
P_new->next = NULL; /# Keine weiteren Knoten #/ 





























DIROUT TXT 1286 1-17-87 7:25p 











p.head = p neu; /® Die leere Liste erhält einen Eintrag #/ 





7a] 
vo De] | 





DIROUT TXT 1286 1-17-87 7:25p 


























Listing 6: Allokieren für eine neue Verkettung. 


Übergeben Sie free nie eine Adresse, die Sie nicht 
vorher von calloc, malloc oder realloc erhalten 
haben, sonst gibt es Probleme. Jedem Block stehen Infor- 
mationen zur internen Systemverwaltung voran, wie die 
Größe des Blocks und ein Zeiger auf den nächsten Block. 
Ist diese Verwaltungsinformation zerstört, so ist der Pool 
des freien Speichers »verschmutzt«. Die dynamischen Allo- 
kierfunktionen tun so, als ob freier Speicher bereits allokiert 
wäre, oder schlimmer, daß bereits allokierter Speicher frei 
für die Wiederallokierung ist. 

Um die Konzepte für die dynamische Speicherverwal- 
tung zu verdeutlichen, sehen wir uns eine Applikation an, 
die ein Inhaltsverzeichnis sortiert. Das Inhaltsverzeichnis 
einer Diskette enthält eine unbekannte, nicht vorhersagbare 
Anzahl von Einträgen. Ein Inhaltsverzeichnis-Sortierpro- 
gramm kann daher zwei verschiedene Wege beschreiten. 
Entweder wird eine festgelegte Größe vorher bestimmt, 
oder die Sortierroutine kann so ausgelegt werden, daß sie 
allen verfügbaren Speicher benützt. Obwohl das Programm 
einfach erscheint, ist es ein gutes Beispiel für die dynami- 
sche Speicherallokierung, und zeigt die Speicherverwal- 
tungstechnik der verketteten Listen. 


Definition des Problems 


Die Anzahl der Dateien in einem Inhaltsverzeichnis kann 
sich unvorhersagbar ändern. Inhaltsverzeichnisse können 
von zwei (».« und »..« - ein leeres Unterverzeichnis) bis zu 
der jeweiligen Obergrenze der Betriebssystemversion mög- 
lichen Einträge aufweisen. Da sich die Obergrenze mit der 
nächsten Version ändern kann, sollte ein Dienstprogramm 
zum Sortieren eines Inhaltsverzeichnisses diese Änderungen 
ohne Neuprogrammieren akzeptieren. 

Das Kommando DIR gibt die Informationen über die 
Dateien in einem Inhaltsverzeichnis aus. Die Reihenfolge 


Listing 7: Die erste Verkettung. 


der Anzeige ist aber nicht sonderlich hilfreich. Eine Lösung 
für beide Probleme wird im folgenden erörtert. 

Das MS-DOS Filterprogramm SORT kann zum Sortie- 
ren der Anzeige verwendet werden. Sie müssen SORT nur 
mitteilen, ab welcher Spalte es sortieren soll und es erledigt 
die Aufgabe. Die Verwendung einer Pipe mit den Kom- 
mandos SORT und DIR ist nützlich aber etwas einge- 
schränkt. 

Des weiteren handhabt SORT einige Dinge recht kläg- 
lich. Eine am frühen Nachmittag geänderte Datei wird vor 
einer am späten Vormittag geänderten Datei angezeigt, da 
MS-DOS (US) »a« und »p« zum Repräsentieren von A.M. 
(vormittags) und P.M. (nachmittags) statt der 24-Stunden- 
Anzeige verwendet. Die Kombination von DIR und SORT 
kann hilfreich sein, aber es wird etwas Besseres benötigt. 


Verkettete Listen 


Verkettete Listen sind mächtige und flexible Werkzeuge um 
dynamisch allokierten Speicher zu verwalten. Sie eignen 
sich in Anwendungen, wo Daten unterschiedlicher Typen 
(Integer, Zeichen und Fließkommazahlen) in Strukturen 
mit nicht vorhersagbarer Länge verkettet werden können. 
Jedes Element einer verketteten Liste ist wie ein Satz in 
einer speicherresidenten Datendatei. Ein Satz enthält 
Schlüssel für andere Sätze, indem er darauf zeigt. Diese 
Sätze sind in Strukturen von einer einfachen Einzelverket- 
tung bis zu exotischen Verkettungs-Netzwerken verkettet. 

Verkettete Listen existieren in  unterschiedlichen 
Größen und Gestalten, mit einigen Gemeinsamkeiten und 
einer einheitlichen Terminologie. Sie können in der Struk- 
tur ziemlich komplex sein. Wir sehen uns die einfachste 
Form, die einfach verkettete Liste an, die eine Reihe von 
Elementen, Knoten genannt, enthält, die zu einer Kette 
verknüpft sind. Es ist nur möglich, sich durch diese Liste in 
einer Richtung zu bewegen, vom Startknoten der Liste, dem 
Kopf, zu dem Endeknoten, dem Schwanz. 

Durch die Einfachheit, mit der Knoten zwischen zwei 
Knoten eingefügt werden können, eignen sich Listen vor- 
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/m Ei eines zweiten EuReaeR und zuweisen der Daten #/ 
p,new = (struct s_dir_node #) malloc(struct s_dir_node)); 


strepy(p new->dir line, 
PP feno TAT 46 11-18-86 6:26p”); 
p_new->next = NULL; /® Noch kein weiterer Knoten */ 








p.head| 3308 
[7] 


[pe Il MED TAT 46 11-18-86 6:20p | 


Listing 8: Allokieren weiterer Verkettungen. 








| pırour er 1286 1-17-87 7:25p | 























züglich zum Speichern von Daten in unterschiedlichen Sor- 
tierungen, Wird jeder neue Knoten einer Liste am Kopf 
eingefügt, dann verhält sich die Liste wie ein Push-Down- 
Stack (auch Last in First out oder LIFO genannt). Werden 
neue Knoten nur an das Ende der Liste angehängt, ist das 
Ergebnis eine First in First out-Schlange (FIFO). Jede Ord- 
nung ist möglich, da neue Knoten überall eingefügt werden 
können. Das alphabetische Sortieren von Text ist leicht zu 
bewerkstelligen. 

Die Daten im Listing 4 werden vom DIR-Kommando 
ausgegeben, und werden benutzt, um zwei Arten von ver- 
ketteten Listen zu erzeugen: zuerst einen Push-down-Stack, 
und dann eine sortierte Liste, Das Erzeugen eines Push- 
down-Stacks von einer leeren Liste ist in den Listings 5, 6, 7, 
& 9 und /0 dargestellt. Die Liste selbst ist im Listing 11 dar- 
gestellt. Ein Speicherabbild, das den Zustand der Liste nach 
jedem Codefragment zeigt, ist den Listings 5, 6, 7, 8, 9 und 
10 beigefügt. 

Die Struktur s_dir_node ist im Listing 5 zusammen 
mit den Zeigern p_head und p_new, die auf diese Struktu- 
ren zeigen, deklariert. Das Strukturmitglied next ist 
ebenfalls ein Zeiger auf eine s_dir_node-Struktur. Diese 
Art der Struktur wird selbstreferenzierend genannt, da sie 
einen Zeiger auf den eigenen Datentyp enthält. Das Mit- 
glied next dient zum Verketten der Strukturen, um die 
Liste zu bilden. Dem Zeiger auf den Kopf, p_head wird 
der Wert NULL (aus stdio.h) zugewiesen, um die leere 
Liste zu erzeugen. 

Der Speicherplatz zum Unterbringen eines einzelnen 
s_dir_node-Knotens wird dynamisch mit der Funktion 
malloc in Listing 6 allokiert. Das Argument, das malloc 
übergeben werden muß, ist die Anzahl der Bytes, die benö- 
tigt werden. Der Zeiger, der vonmalloc zurückgegeben 


70 Microsoft System Journal Juli/August 1988 


[p_new->next = p_head; 
/* Neuer Eintrag zeigt auf den Listenkopf ®/ 


[ soon |[ DIROUT TAT 1206 1-17-87 7:259 ] 
n 








ee 
3800 || NEMO TXT 46 11-18-86 6:26p 














Listing 9: Die zweite Verkettung. 


wird, ist die Adresse des neu allokierten Blocks, aber vom 
Typ Zeiger auf char, und muß deshalb auf einen Zeiger 
vom Typ s_dir_node mit dem cast (struct s_dir_ 
node *) konvertiert werden. Die typkonvertierte Adresse 
wird der Variablen p_new als letzte Aktion des ersten 
Statements zugewiesen. Das Speicherdiagramm zeigt, daß 
der neue Knoten an Adresse 3800 steht. 

Die letzten beiden Statements im Listing 6 weisen dem 
allokierten Knoten Werte mit dem Operator -> zu. Der 
Ausdruck p_new->dir_line ist das Mitglied dir_line 
in der Struktur s_dir_node, auf die p_new zeigt. 
p_next->next wird NULL zugewiesen, um es als Schwanz 
der Liste kenntlich zu machen. Dieser Knoten ist zugleich 
Kopf der Liste. 

Durch die Zuweisung in Listing 7 zeigt p_head auf den- 
selben Knoten wie p_new. Im Listing 9 wird ein neuer 
Knoten an Adresse 3900 allokiert. Die kombinierten Aktio- 
nen in den Listings 9 und 10 plazieren in Push-down-Stack- 
Weise den zweiten Knoten an den Kopf der Liste vor den 
vorherigen Kopf. 

Die for-Schleife im Listing 11 zeigt jeden Knoten an, 
beginnend beim Kopf zum Ende fortschreitend, einen je 
Durchlauf. Ein interessanter Aspekt der Schleife ist, daß 
statt eines Hoch- oder Niederzählens durch eine Liste von 
Zeigern geschritten wird. Der Ausdruck p_new = p_new-> 
next zeigt dieses Durchschreiten, indem p_new der Wert 
des Mitglieds next zugewiesen wird. 

Beachten Sie, daß im Formatstring für printf, inner- 
halb der Schleife, der Formatbezeichner %u (unsigned 
integer) zur Anzeige der Adressen verwendet wird, da 
Adressen nie negativ sind. 

Da Sie jetzt erste Erfahrungen im Erstellen von verket- 
teten Listen haben, schauen Sie sich einen Augenblick den 
Vergleich zwischen verketteten Listen und Arrays im Listing 
12 an. Verkettete Listen vereinfachen den Umgang mit 
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p_head = p_nev; /* Die Liste vachst, jetzt 2 Einträge */ 








MENO TAT 


46 11-18-86 6:26p 

















DIROUT TXT 1286 1-17-87 7:25p 

















Listing 10: Die Verkettung ist beendet. 


nicht vorhersagbaren Datenmengen. Die Folge der Daten 
kann leicht geändert werden, da leicht ein Knoten oder eine 
Folge von Knoten zwischen zwei existierende Knoten der 
Liste eingesetzt werden können. Ebenso einfach ist das 
Herausnehmen von Knoten oder einer Folge von Knoten. 

Der Zugriff auf unterschiedliche Elemente eines Arrays 
ist schr schnell und erlaubt wahlfreien Zugriff. Auf die 
Elemente einer verketteten Liste muß in der Reihenfolge 
vom Kopf Knoten für Knoten bis zum Schwanz zugegriffen 
werden. Verschiedene Pfade (Ordnungen) durch eine ver- 
kettete Liste können durch Hinzufügen von neuen Zeigern 
in der Struktur erreicht werden. Die Bezeichnung doppelt 
verkettete Liste steht für eine Liste, die ebenso Zeiger zum 
Vorgängerknoten enthält. Der zusätzliche Aufwand des 
Speicherns der Verkettungszeiger in jedem Knoten ist ein 
Preis, der bei verketteten Listen, aber nicht bei Arrays zu 
zahlen ist. Diese Tatsachen in Erinnerung behaltend, wollen 
wir mit einer realeren Applikation für verkettete Listen 
fortfahren. 


Das Programm BY_TIME 


Das Programm BY_TIME kann zum Sortieren der Aus- 
gabe des DIR-Kommandos benutzt werden. Die Informa- 
tion wird in der Reihenfolge des Datums und der Uhrzeit 
angezeigt, wobei die jüngsten zuerst angezeigt werden. Das 
Sortieren wird mit Hilfe des Einfügens von Knoten in eine 
verkettete Liste durchgeführt, die ständig in der richtigen 
Sortierfolge vorliegt. Das DOS-Kommando zum Ausführen 
des Kommandos BY_TIME, um *. EXE-Dateien in Datum- 
und Uhrzeit-Reihenfolge auszugeben, schen Sie in Listing 
13, zusammen mit einer Beispielausgabe. 

Die Organisation und Struktur des Programms 
BY_TIME zeigt einen Codierstil, der zum Entwickeln 
größerer Applikationen geeignet ist. Die main-Funktion 
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/" Nach dem Anlegen der rue Liste vird diese in einer 
for-Schleife angezeigt ®/ 


for(p new = p_head; p new t= NULL; p_new = p_new->next. 
printf("Adresse: Au, next: a, Üir_line: %-. al - 
p_new, p_new-next, p_nev->dir_line); 


Ausgabe: 





Adresse: 3900, next: 3800, dir_line: MEMO RT 
Adresse: 3880, next: 8, dir_line: DIROUT TXT 








Listing 11: Ergebnis der Ausgabe der verketten Liste. 


verbirgt die Details der Datenmanipulation, die in den unte- 
ren Funktionen durchgeführt werden, gibt aber einen 
schnellen Überblick über die durchgeführte Bearbeitung. 
Jede Funktion ist kurz und prägnant und erledigt eine ein- 
zige Aufgabe. Keine externen Daten werden benötigt. Die 
Datenpfade, in denen die Informationen fließen, werden 
durch die Argumentübergabe klar. 

Das Programm BY_TIME erhält man durch das 
getrennte Übersetzen aller C-Quelldateien und das Linken 
der entstandenen Objektdateien (der Listings 14, 15, 16, 17, 
18, 19 und 20). 

Jeder Knoten in der verketteten Liste von BY_TIME ist 
eine vertraute Struktur mit zwei Mitgliedern, einem Zeiger 
auf einen anderen Knoten und einem String von Informa- 
tionen über die Dateien, die von DIR ausgegeben werden. 
Die Struktur der Knoten ist in der Headerdatei BY_TIME.H 
im Listing 14 definiert und kann somit in jede Quelldatei, 
die sie benötigt, eingelesen werden. 

Die erste Aktion der Funktion main im Listing 15 ist der 
Funktionsaufruf von bgn_list mit dem Argument eines 
Kopfknoten, der als s_dir_node-Struktur deklariert ist. 
Die Funktion bgn_list im Listing 16 weist Dummydaten 
zu, womit gewährleistet ist, daß der Knoten immer der Kopf 
der Liste bleibt. Dieser spezielle Kopf hilft, das Programm 
sauber zu gestalten, da der Kopfknoten beim Einfügen nicht 
als Spezialfall berücksichtigt werden muß. Der Kopf der 
Liste ist nicht dynamisch allokiert, sondern ist eine gewöhn- 
liche auto-Strukturvariable. 

Die initialisierte Liste ist jetzt vorbereitet, um mit der 
Information der Dateien zu wachsen. Die while-Schleife in 
main führt wechselweise get_dir- und sav_dir- Funkti- 
onsaufrufe durch, bis get_dir ® zurückgibt. Jeder Funk- 
tionsaufruf von get_dir (Listing 17) fügt eine Zeile von 
Dateiinformationen in den übergebenen Puffer. Er gibt bei 
Erfolg 1, ansonsten © zurück (Ende der Eingabe). 

Nach der Rückgabe der ersten DIR-Information von der 
Funktion get_dir wird der erste Block dynamischen Spei- 
chers allokiert und wie im Listing 18 gezeigt zur Verwen- 
dung an die Funktion sav_dir übergeben. 


Microsoft C und Q 


Verkettete Listen Arrays 





Variable Länge Feste Dimensionierung 


mit Maximalgröße 


Unterstützt keinen 
zusätzlichen Speicher 


Kann zusätzlichen 
Speicher ansprechen 


Schnelles Einfügen 
und Löschen 


Löschen und Einfügen 
langsam 


Kein wahlfreier, 
nur sequentieller 
Zugriff 


Direktzugriff 


Zusätzlicher Speicher Kein zusätzlicher 
für Knotenzeiger Speicherbedarf 


Programme zur Programme zur 


Listenmanipulation Arraybearbeitung 
sind schwer sind leicht 
zu lesen lesbar 





Listing 12: Vergleich von verketteten Listen und Arrays 


Die Funktion sav_dir hat die Aufgabe, die neuen 
Knoten so in die Liste einzufügen, daß sich die Liste in der 
entsprechenden Reihenfolge befindet. 

Das Einfügen beginnt mit einer Schleife, die die Liste 
nach dem korrekten Einfügepunkt durchsucht. Die Funk- 
tion time_b4 im Listing 19 wird in der for-Schleife von 
sav_dir als Bedingungstest aufgerufen. Die Funktion 
time_b4 vergleicht Datum und Uhrzeit des Eingabepuffers 
mit dem Datum und der Uhrzeit im Knoten der Liste und 
gibt 1 zurück, wenn die Pufferzeit älter ist, ansonsten 0. 

Speicher für neue Knoten wird in der Funktion 
sav_dir durch den Funktionsaufruf von malloc dyna- 
misch angefordert. Beachten Sie, daß ein Test auf NULL 
durchgeführt wird, um sicherzustellen, daß genügend Spei- 
cher für den neuen Knoten vorhanden ist. Die letzten bei- 
den Statements in sav_dir lösen die Verbindung zwischen 
den beiden Knoten, fügen den neuen Knoten ein, und 
erzeugen dadurch eine geordnete Liste, die um ein Element 
länger ist. 

Jede DIR-Ausgabezeile wird von der Funktion 
sho_list im Listing 20 angezeigt, indem sie vom Kopf 
zum Schwanz die Liste durchwandert. Dies wird durchge- 
führt, nachdem die Eingabe beendet und die Liste erstellt 
ist. Das Programm in sho_list geht durch die Liste, den 
Datenteil jedes Knotens anzeigend, so wie es auch die 
Schleife in Listing 11 erledigte. 


Wilde Zeiger 


Wie schon am Beispiel von free gezeigt, muß bei der Spei- 
cherverwaltung in C aufgepaßt werden, ganz besonders 
beim Datenzugriff über Zeiger. Das Programm DANGLE.C 








DIR =.EXE | BY_TINE 


449 
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Listing 13: Ausgabe des Programms BY_TIME. 


im Listing 21 ist ein Beispiel für Speicher-Mismanagement, 
da es Speicher im nicht allokierten Speicher anspricht. Die 
Resultate ergeben beim ersten Anblick keinen Sinn, bis Sie 
erkennen, daß ein häßlicher Fehler im Spiel ist. Die Aus- 
gabe besteht aus drei verschiedenen Zeilen von Schrott. 
Versuchen Sie es selbst. 

Der Speicher, auf den p_next zeigt, war in keinem der 
drei Fälle allokiert, in denen die Adresse an die Funktionen 
puts und printf zur Ausgabe übergeben wurde. Der 
Speicher war allokiert, während str _dang ausgeführt wird, 
aber nach der Rückkehr ist die Adresse der auto-Vari- 
ablen auto_string, der Speicher für auto_string 
deallokiert. Automatische Variablen innerhalb einer Funk- 
tion werden deallokiert, wenn die Funktion zum Aufrufer 
zurückkehrt. Danach wird der Speicher von auto_string 
reallokiert, so daß der String, auf den p_next zeigte, sich 
ändert, wie wenn böse Geister im Spiel wären. Der nächste 
Gebrauch war für printf oder eine seiner Unterfunktio- 
nen gedacht. 

Speicher für alle statischen oder externen Variablen 
eines Programms bleibt für den gesamten Programmlauf 
allokiert. Wäre die Deklaration von auto_string durch 
das Wort static eingeleitet worden, erhielten Sie statt der 
drei falschen Zeilen die drei gleichen Zeilen 123456789. 


Zusammenfassung und Ausblick 


Programme, die unvorherschbare Mengen von Daten im 
Arbeitsspeicher bearbeiten müssen, profitieren von dyna- 
misch allokierten Arrays. Diese Arrays können aus ein- 
fachen Datenelementen oder aus komplexen Strukturen 
bestehen. Nach dem Allokieren kann auf diese dynamischen 
Arrays durch die Verwendung der eckigen Klammern [] 
zugegriffen werden, um einzelne Elemente anzusprechen, 
so wie bei gewöhnlichen Arrays. 

Bedarf die Datenbearbeitung eine Änderung in der 
Reihenfolge der Elemente, dann sollten verkettete Listen in 
Erwägung gezogen werden. Die Entscheidung wird anhand 
des Zugriffs auf die Daten getroffen. Wird häufig wahlfreier 
Zugriff benötigt, oder wird die Liste nur in sequentieller 
Folge bearbeitet? Ist der Mehraufwand von Knotenzeigern 
in jedem Knoten vertretbar? Sind die Personen, die die 
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Fi 
vn] TINE.H: Header-Datei für das Programm BY_TIME, die die 
verkettete Listenstruktur definiert 


” 
#define DIR LINE LEN 39 In a von DIR ®/ 
struct s_dir_node { il ‚ten Liste ®/ 


struct s_dir_node #next; DE Ze zum alten Ken 
/* oder NULL ®, 
char dir_line[DIR_LINE_LEN + 1); /* DIR Ausgabezeile */ 





Listing 14: BY_TIME.H. 





VERERPLRRLRLRDEE EEE? nun 
A BYTINE.C: Filter, der die DIR Ausgabe in einer verketteten 
Liste sortiert. Hier die Hauptfunktion des 





3 
v 


#include <stdio.h> 
include "by_tine.h” 


/* Für BUFSIZ w/ 
/® Struktur der verketteten Liste ®/ 


mul) 
struct s_dir node head;/* Listenkopf #/ 
char in \_buFLBUFSIZ]; /* Eingabepuffer für DIR Ausgabe #/ 


ben lie /* Liste initialisieren #/ 
Ie ET ielinı ‚buf)) /* DIR-Info für nächste Datei */ 
irTin_buf, BA); bar Speichern in einer ®/ 
'* sortierten verketteten Liste #/ 


sho_list(&head); a Anzeige der Liste »/ 











Listing 15: BY_TIME.C, 


Programme warten, sattelfeste C-Programmierer, die sich 
mit Zeigern, dem dynamischen Allokieren und der Theorie 
der verketteten Listen auskennen? 

Hier wurde nur die einfach verkettete Liste besprochen. 
Die doppelt verkettete Liste, die vor- und rückwärts durch- 
laufen werden kann, wurde nur erwähnt. Ein Baum ist ein 
weit komplexerer Typ einer verketteten Liste. Der Kopf 
eines Baums kann zwei oder mehrere Zeiger auf Strukturen 
haben, die oftmals Nachfolger genannt werden, wie in 
einem Familienstammbaum. Jeder der Nachfolgerknoten 
kann wieder mehrere Nachfolger haben. Knoten ohne 
Nachfolger werden Blätter genannt. In einem Baum sind 
keine Schleifen erlaubt, ebenso wie eine Person nicht sein 
eigener Vater oder Opa sein kann. Anwendungen für 
Bäume sind Sortieren, Ausdrucksbewertung in Compilern 
und Übersetzern sowie das Bearbeiten von Verzeichnissen 
und Unterverzeichnissen auf Datenträgern. 

Für mehr Informationen über das Speichermanagement, 
die dynamische Allokierung und verkettete Listen empfehle 
ich das Kapitel »Optimale Speicherausnutzung« in meinem 
Buch »Variationen in C« (Vieweg/Microsoft Press, 1987). 

Die Güte der Speicherverwaltung macht für den An- 
wender einen wirklichen Unterschied in der Güte eines Pro- 
gramms aus. Machen Sie Ihre Zeiger nicht wild, und Ihre 
Listen bleiben in Verbindung. Steve Schustak 
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* BGN LIST.C: Initialisieren des Listenkopfs mit den 
4) r gröetadglichen Nert. 

“ 


include <stdio.h> 
include "by_tine.h” 


st(; 
s Ya) node *p_head;/* Zeiger auf Listenkopf ®/ 


/* Datum im Kopf ist größer als alle anderen ®/ 


strepy(p head-»dir line, 
mızzztızz TIL 99999 99-99-99 99:99p”); 
p_head->next = NULL; /# Kein Nachfolger - leere Liste »/ 


/* Für NULL Zeiger #/ 
7x Struktur der verketteten Liste ®/ 











Listing 16: BGN_LIST.C. 





VELLLELLTLEETTERUTTLEUTLEETLLEUTT UT TDEUTLEITLEEUTIIL DEU TUT 
® GET_DIR.C: Eingabe der DIR-Inforsation für die nächste Datei 
* von stdin 

%Y 

include <stdio.h> 
Ant t_dir(buf) 
char Kur, 


/* Für NULL Zeiger #/ 
% Puffer zum Lesen und zur 
/# Rückgabe der Zeile Di 


char *rtn; /# Rückgabe von gets() %/ 


/® Schleife: 
Eingabe bis Ende, oder bis Zeile 
mit Gropbuchstaben beginnt #/ 


while ((rtm = getstbuf)? a8 /r Eingabe einer Zeile »/ 
(Burehie eRr 11 Bunte) Serze3) 
return(rtn t= NULL); 


Listing 17: GET_DIR.C. 





RER EL 
® SAV_DIR.C: Allokieren eines neuen Knotens und das 

y Abspeichern der DIR-Inforsation 

“ 


include <stdio.h> 
'Zinelude "by_tine.h" 


Say. äirtbof, p_head) 
char *bu: 


/* Für NULL Zeiger ®/ 
/" Struktur der verketteten Liste */ 


/®* Zeile der DIR Ausgabe ®/ 


struct s_ "ar -_node *p_head; /" Zeiger auf Listenanfang ®/ 
/* Zeiger auf nächsten #/ 


struct s_dir_node ®p_next; 
/* Knoten in der Liste #/ 
struct s_dir_node "old_p_next; In Zeiger zum Nachfolger ®/ 


/" des Vorgängers ®/ 
struct s_dir_node *p_new; /n Zeiger auf neuen Knoten */ 


/x Schleife: 
Für jeden Knoten in der Liste bis zum Ende, oder 
bis der Punkt zus sortierten Einfügen erreicht ist #/ 

















for (next. = p_head-Jnext, old.p next, = p_heaa; 
P next h& time bilbuf, pinext); 
ETa.p next = Pinext, D.Rext = pnext-Inext) 


/# Dynamisches Allokieren neuer Knoten. 
Beachten Sie den cast (struct s_dir_node *) 
Br ‚eine Warnung zu vergeiden. 


p_nev = (struct s dir node ®) 
Se (eiet(etrct s_dir_node)); 


4f (p_new == NULL) ( /* malloc() Fehler, 2 
/# kein icher mehr *, 
paalekein freier Speichert?1"); 
return; 


strepy(p_new->dir line, buf), /# Speichern der DIR Zeile im 
neu allokierten Speicher ®/ 

p_new->next = old_p_next-next;/" Neuer Knoten zeigt auf 
Listenrest */ 

/# Einfügen des neue: 


old_p_next->next = p_new; 
Knoten in der Liste “ 


| 


5 TIRE_B4.C: Rückgabe yon 1, falls Datun und Uhrzeit, in but 
früher ist, als von Knoten p_next, sonst 


” 
Zinetude Toy tine.h” /# Struktur der verketteten Liste #/ 
E- ilte: x Zeite der DIR Ausgabe »/ 
Struct s.dir_node "p_next;/" Zeiger auf den Vergleichsknoten #/ 
int rin; ‚/# Rückgabe von strncap() #/ 


/* Vergleich von Jahr, Monat, Tag, an/pm, Stunde und Minute #/ 
1ftrtn = strncap(&burt29], Atp_next->dir_Lne)l29}, 23) 
ren 2 «"Unterschled 


Jahr %/ 
if(rtn = aburtzs), &(p_next->dir meta; 2) 
return(rtn < 8); /# Unter: Monat ®/ 
if(rtn = Sirneptähuta6), &(p_next->dir Tina, Rn 
return(rti ); Unterschied Tag %/ 
ER 1 Apex next-. Bor _l1ne)[38])/® Unterschied an/pn %/ 


Wurde), &(p_next->dir line)[33], 2)) 
(rtn rapie), Alp_next Sao D Ki 
if = m 
return(rt ); = '* Unterschied Minute #/ 
PR /* Datum Re Uhrzeit sind gleich #/ 








Listing 18: SAV_DIR.C. 


Listing 19: TIME_B4.C. 





DELELETTLLLILTLLTTLLDETILTLELLUTTLLLTTTRESTLIEL UT TTTTEETer ren 
4 SHO_LIST.C: ee ‚e einer verketteten Liste 

’ nach stdout 

h 


include <stdio.h> 


/* Für NULL Zeiger ®/ 
‚Anclude "dy_tine.h" 


/* Struktur für verkettete Liste ®/ 

sho_list(p_head) 

strüet s_dIr_node *p_head;/® Zeiger auf Listenbeginn #/ 

struct s_dir_node *p_next; /® Zeiger auf nächsten Knoten ®/ 

for(p_next = BJ head->next; /" Start beim ersten Knoten #/ 
p_next != NULL; /* Weitere Elemente? »/ 
P_next = p_next-next) /w Nächster Knoten #/ 


puts(p_next->dir_ line); /# Ausgabe der Zeile ®/ 








VALLETELTELESTETETTETEITELTTESTUTSTUITSTETETELTITSTETEITITETTTT 
$ DANGLE.C: Gefahr beim Referenzieren eines Zeigers auf 
deallokierten Speicher 








D 
ain() 
char pt 
Be = str_dang(); 
puts(i en 
PintETRS\nE, text); 
} printf("8s\n*, p_text); 
ger_dangt) 


char auto_string[18]; 


strepy(auto_string, augen 
return(&auto_stringL#]) 











Listing 20: SHO_LIST.C. 


Listing 21: DANGLE.C - hüten Sie sich vor wilden Zeigern. 
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Ihr erster MS-DOS Gerätetreiber 


»Das Programmieren eines Gerätetreibers ist 
eine schwierige, aufwendige Angelegenheit, die 
nur Betriebssystemgurus wagen sollten.« Wer 
dieses Vorurteil hat, hat einfach unrecht, denn 
das Programmieren eines Gerätetreibers ist 
weder sehr unterschiedlich vom Schreiben eines 
anderen Programms, noch ist es wesentlich 
schwieriger. 


Dieser Artikel beleuchtet das Innenleben eines Gerätetrei- 
bers und bietet einige nützliche Tips und Techniken zum 
Debuggen eines Gerätetreibers. Der hier beschriebene 
Gerätetreiber MDM_DRV dient als einfaches Kommuni- 
kationsprogramm mit Xmodem-Prüfsummen-Protokoll. 
Obwohl es dasselbe Programm an der anderen Seite der 
Leitung oder des Modems erwartet, kann es auch Dateien 
aus einigen Mailboxen laden. 

Ein Gerätetreiber ist das logische Interface zwischen 
dem Ein-/Ausgabe-System des Betriebssystems und der 
darunterliegenden Hardware. In einigen Fällen ersetzt der 
Gerätetreiber Teile des BIOS oder erweitert sie, und muß 
daher die Hardware direkt ansteuern. In anderen Geräte- 
treibern wird die physikalische Ein-/Ausgabe nur vom 
BIOS durchgeführt. Frühere DOS-Versionen erlaubten 
keine einfache Installation von Gerätetreibern. Seit der 
Version 2.0 kann der Programmierer aber das Betriebs- 
system leicht erweitern. Da die Systemschnittstelle für 
Gerätetreiber klar definiert ist (im Gegensatz zu Hinter- 
grundprogrammen, TSRs), »vertragen« sich die Geräte- 
treiber in der Regel mit ihren Artgenossen. 

Gerätetreiber gibt es in zwei Ausführungen: zeichen- 
und blockorientiert. Gerätetreiber, die das Speichern 
und/oder Lesen von Daten auf Disketten oder anderen 
Speichermedien mit wahlfreiem Zugriff erlauben, sind ge- 
wöhnlich Block-Gerätetreiber. Sie übertragen Daten in 
festen Blockgrößen, daher auch ihr Name. 

Dieser Artikel beschränkt sich auf Zeichen-Gerätetrei- 
ber. Zeichen-Gerätetreiber müssen in einem von zwei Modi 
arbeiten: cooked oder raw. Der Cooked-Modus führt 
einfach Anforderungen an den Gerätetreiber für jeweils ein 
Zeichen durch und bearbeitet besondere Fälle wie Carriage 
Return oder Line Feed, die übersetzt werden können oder 
nicht. Bei jeder Eingabe wird eine Statusüberprüfung 
durchgeführt, um zu erkennen, ob [Cantroi)(C) gedrückt 
wurde, und ein Gerätetreiber, der im Cooked-Modus arbei- 
tet, erlaubt MS-DOS in diesem Fall, den Treiberaufruf 
abzubrechen. Da das aufrufende Programm nicht wissen 
muß, ob der Gerätetreiber im Cooked- oder im Raw- 
Modus arbeitet, muß MS-DOS die typische Ein-/Ausgabe- 
Anfrage für mehrere Byte vom Programm in die richtige 
‚Anzahl Aufrufe für Einzelbytezugriffe umsetzen. MS-DOS 
erledigt dies unter Zuhilfenahme von Puffern, die nach 
Abarbeiten des Aufrufs übertragen werden. 
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Offset des Zeigers zum nächsten Gerätetreiber 
Segnent des Zeigers zum nächsten Gerätereiber 








Zeiger auf die Strategy-Routine 


Zeiger auf die Interrupt-Routine 


Logischer Nane (8 Zeichen) bei Zeichengeräten. 
Anzahl der Einheiten (1 Zeichen) für Blockgeräte, 
gefolgt von 7 Leerstellen. 











Bild 1: Header eines Gerätetreibers. 


Im Raw-Modus wird keine Übersetzung oder spezielle 
Bearbeitung durchgeführt, weder vom Gerätetreiber, noch 
von MS-DOS. Im Raw-Modus gibt es keine Einzelbyte- 
zugriffe, der Gerätetreiber muß in der Lage sein, eine 
Anforderung für eine bestimmte Anzahl von Byte zu erledi- 
gen. Diese Zugriffe benötigen in der Regel keine von MS- 
DOS bereitgestellten Puffer, sondern werden in Puffern des 
Anwendungsprogramms durchgeführt. Deshalb ist der 
Raw-Modus effizienter, als der Cooked-Modus. 

Der Anwender kann den Modus von raw nach cooked 
und umgekehrt ändern, indem er den Funktionsaufruf 
IOCTL (Interrupt 21H mit AH =44) durchführt. 


Die Struktur der Gerätetreiber 


Die drei Hauptteile des Gerätetreibers sind der Header, die 
Strategy- und die Interrupt-Routine. Der Header beschreibt 
die Fähigkeiten und Attribute des Treibers, benennt den 
Zeichen-Gerätetreiber, besitzt NEAR-Zeiger (nur Offset) 
auf die Strategy- und Interrupt-Routine und FAR-Zeiger 
(Segment und Offset) auf den nächsten Gerätetreiber in der 
Kette der Treiber. Diese Kette enthält nur Vorwärtsver- 
weise, was Probleme beim Auffinden des Anfangs verur- 
sacht. Der Zeiger auf den nächsten Treiber wird von MS- 
DOS unmittelbar nach dem Ausführen der Initialisierungs- 
routine gesetzt, und muß anfänglich im Treiber auf -1 
(FFFFFFFFH) gesetzt werden. 

Der Gerätetreiber darf maximal 64 Kbyte groß sein, da 
die Zeiger auf die Strategy- und Interrupt-Routinen nur in 
ein Segment zeigen können. Den Header sehen Sie in Bild 1 
und eine Beschreibung der Bits im Attributwort in Bild 2. 


Die Strategy-Routine 


Die Strategy-Routine wird beim Installieren während des 
Bootvorgangs und bei jedem vom Betriebssystem generier- 
ten Aufruf aufgerufen. Eine einzige Ein-/Ausgabe-Anfor- 
derung des Anwendungsprogramms kann mehrere Ein-/ 
‚Ausgabe-Anforderungen für den Treiber erzeugen. 


KURS DTORET 





Bit Beschreibung 


15 0 falls Blockgerät 
1 falls Zeichengerät 
14 0 IOCTL wird nicht unterstützt 
1IOCTL wird unterstützt 
13 _0(falls Bit 150 ist) IBM-Format 
1 nicht IBM-Format 
0 (falls Bit 15 1 ist) 
‚Ausgabe bis Busy wird nicht unterstützt 
1 Ausgabe bis Busy wird unterstützt 
2 0 Undefiniert 
1 0 Nur DOS 2.x Aufrufe 
1DOS 3.x. Aufrufe. 
Aufrufe für Open/Close Device und wechselbares 
Medium werden unterstützt. Diese werden bei 
DOS 2.x ignoriert. 
0 Undefiniert 
0 Undefiniert 
0 Undefiniert 
0 Undefiniert 
0 Undefiniert 
0 Undefiniert 
0 Undefiniert 
0 Normales Gerät 
1 Spezial Uhr-Gerätetreiber 
0 Normales Gerät 
1 Null-Gerätetreiber 
0 Normales Gerät 
1 Standard-Ausgabegerätetreiber 
0 0 Normales Gerät 
1 Standard-Eingabegerätetreiber 


Bild 2: Attributwort des Gerätetreibers. 





wauano 
25 


» 


r» 





Zweck der Routine ist das Speichern der Adresse für die 
spätere Bearbeitung und die anschließende Rückkehr. Die 
im Registerpaar ES:BX übergebene Adresse zeigt auf eine 
Struktur, die Request Header (Listing I) genannt wird. Diese 
Struktur enthält Informationen für den Gerätetreiber, um 
ihm mitzuteilen, was er auszuführen hat. 

Wichtig ist, daß keine Ein-/Ausgabeoperationen von der 
Strategy-Routine durchgeführt werden und daß die Adresse 
des Request-Headers vom Treiber für die spätere Bearbei- 
tung abgespeichert wird. In einem echten Multitasking- 
System würde diese Adresse wahrscheinlich in einem Array 
gespeichert und nach einer Methode, die die optimale Ge- 
räte-Ausnutzung garantiert, sortiert. MS-DOS führt unmit- 
telbar auf den Strategy-Routinen-Aufruf den Interrupt- 
Routinen-Aufruf durch. Ein wichtiger Punkt ist, daß die 
Interrupts zwischen dem Strategy- und dem Interrupt-Rou- 
tinenaufruf nicht gesperrt sind: Das kann Probleme verur- 
sachen, wenn Ihr Gerätetreiber davon ausgeht, daß zwi- 
schen beiden Routinenaufrufen keine Verzögerung vorhan- 
den ist. 








rlength db 8 De der Daten im Header 

wit db 8 6 Pd itenummer (nicht in MDM_DRV) 
command db 8 ; 2 - Das aktuelle Kommando 

status dv 8 3 - Rückkehr-Status 

reserve db 8 5 - Reserviert für DOS 

media db 8 13 - Media-Beschreiber (nicht in MDM_DRV) 
address dd 8 ;14 - Zeiger auf EEE 

count dw 8 ‚18 - te Zähler für Zeichen- 
sector dv 8 ‚28 - Startsı (nicht in NDM_DRV) 





Listing 1: Aufbau des Request-Headers. 


Die Interrupt-Routine 


In der Interrupt-Routine wird die eigentliche Arbeit erle- 
digt, und deshalb ist sie der komplizierteste Teil des Trei- 
bers. Beim Aufruf dieser Routine wird das Kommandobyte 
(drittes Byte) des vorher gespeicherten Request-Headers 
untersucht und die entsprechende Aktion ausgeführt. Sie 
schen in Bild 3 eine Liste der Kommandos mit den zuge- 
hörigen Aktionen. 

Die Interrupt-Routine benutzt normalerweise das 
Kommandobyte als Offset für eine Verteilertabelle und ruft 
so die entsprechende Funktion für das Kommando auf. Sie 
können natürlich auch eine Sprungtabelle anlegen, wenn Sie 
möchten. Der Request Header enthält alle Informationen 
für die Bearbeitung und informiert das aufrufende Pro- 
gramm (in der Regel MS-DOS) nach der Bearbeitung über 
den Status. Das Statuswort enthält eine Anzahl Felder (Bild 
4). Es enthält ein Fehlerbit, um anzuzeigen, daß ein anderer 
Teil den Fehlercode enthält. Ein Done-Bit zeigt an, daß die 
Operation vollständig ausgeführt wurde. Ein Busy-Bit wird 
momentan verwendet, um den Zustand des Geräts anzuzei- 
gen. 

Normalerweise ist es nicht ausreichend, den Status der 
Operation zurückzugeben. Oftmals muß die Anzahl der 
bearbeiteten Zeichen zurückgegeben werden, so bei Lese- 
‚oder Schreiboperationen. 

Obwohl die Interrupt-Routine nicht über einen Inter- 
rupt aufgerufen wird, sondern mit einem FAR CALL, sollte 
sie sich wie eine richtige Interrupt-Routine verhalten, und 
alle Register und die Flags retten und am Ende wieder her- 
stellen. Das Routinenende muß ein FAR RET sein. 


Die Kommandos 


Die in Bild 4 dargestellten Kommandos sind in 
MDM DRV als aufrufbare Unterprogramme implemen- 
tiert. Die Sprungverteilertabelle unterhalb des Request 
Headers im Assemblerlisting zeigt auf die benötigten Rou- 
tinen. Von der Interrupt-Routine wird auf die Tabelle zuge- 
griffen, wobei das Kommandobyte des Request Headers als 
Index benutzt wird. 
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Kommando- 

byte Bedeutung 

00H  Initialisierung für den Gerätetreiber. Wird nur 
beim Bootvorgang bei der Treiberinstallierung auf- 
gerufen. 

01H Media Check. Der Rückgabestatus gibt an, ob das 
Medium gewechselt wurde (in MDM_DRV nicht 
verwendet). 

02H Erstelle den BIOS-Parameter-Block. Wird bei 
neuem oder gewechselten Medium aufgerufen. Der 
BPB soll erstellt werden, und die Adresse zurück- 
‚gegeben werden (in MDM_DRV nicht verwendet). 

03H Read IOCTL. Kopiere Gerätetreiber-Informatio- 
nen in einen lokalen Puffer. 

04H Read. Lesen einer Anzahl von Zeichen. 

05H _Non-Destructive Read. Lesen des nächsten Zei- 
chens von dem Gerät, ohne es aus dem Puffer zu 
nehmen. 

06H Input Status. Rückgabe eines Status, der angibt, ob 
ein Zeichen im Eingabepuffer wartet. 

07H Input Flush. Leeren des Eingabepuffers des Geräts. 

08H Write. Ausgabe einer Anzahl von Zeichen. 

09H Write Verify. Ausgabe der Zeichen mit Überprü- 
fung, ob sie korrekt ausgegeben wurde. 

0AH Output Status. Statusrückgabe, die angibt ob das 


Gerät beschäftigt ist oder frei. 

0BH Flush Output Buffers. Leeren des Ausgabepuffers 
des Geräts. 

OCH Write IOCTL. Kopieren einiger Informationen in 
die Gerätetreiber-Tabellen. 

0DH Device Open (nur DOS 3.x). Initialisieren des Ge- 
räts. 

0EH Device Close (nur DOS 3.x). Wird zum Schließen 
der File Handle aufgerufen. 

OFH  Removable Media Routine (nur DOS 3.x). Nur 
Blockgeräte. 


10H Output until Busy (nur DOS 3.x). Erlaubt die 
Rückkehr, bevor die Ausgabe beendet ist. 


Bild 3: Die Bedeutung des Kommandobytes im Request- 
Header. 





Sobald die Strategy- und die Interrupt-Routinen funktio- 
nieren, müssen die Kommandos implementiert werden. 
Dies ist eine geradlinige Vorgehensweise wie Sie im Listing 
sehen können. Alle unten detailliert beschriebenen Kom- 
mandos sind in derselben Reihenfolge vorhanden. Dieser 
Aufbau kann als Grundlage für fast alle Gerätetreiber die- 
nen, unabhängig von ihrer Kompliziertheit. Zur weiteren 
Information über das Programmieren von Gerätetreibern 
können Sie auch das MS-DOS Technical Reference oder das 
Buch MS-DOS für Fortgeschrittene von Ray Duncan (Micro- 
soft Press/Vieweg) heranziehen. 

MDM_DRYV benutzt nicht alle verfügbaren Komman- 
dos, aber Sie werden aus Gründen der Vollständigkeit alle 
dargestellt. Die unbenutzten sind im Quellcode als einfache 
Unterprogramme mit einem Rücksprungbefehl dargestellt. 


78 Microsoft System Journal Juli/August 1988 


15 0 Kein Fehler 
1 Fehler 

14 Reserviert 
3 Reserviert 
2 Reserviert 
1 Reserviert 
10 Reserviert 
9 1 Gerät Busy 
8 1 


Operation beendet. (Liegt eine Fehler- 
bedingung vor, wird dieses Bit ignoriert. 


0-7 Spezifische Fehlercodes: 
0H Schreibschutz 
1H Unbekanntes Gerät 
2H Laufwerk nicht bereit 
3H Unbekanntes Kommando 
4H Datenfehler beim Lesen 
5H Unbekannte Ein-/Ausgabe 
Requeststruktur 
6H Fehler beim Seek 
7H Unbekanntes Medium 
8H Sektor nicht gefunden 
9H Drucker Fehler (Papierende) 
AH _ Schreibfehler 
BH Lesefehler 
CH _ Allgemeiner Fehler 
DH _ Reserviert 
EH _ Reserviert 
FH Mediumwechsel nicht erlaubt 


Bild 4: Statuswort eines Gerätetreibers. 


Jedes benötigte Kommando folgt derselben Logik. Es wird 
von der Interrupt-Routine mit einem NEAR CALL 
aufgerufen, führt seinen Zweck aus und gibt im Register 
AX einen Status zurück. Der Status wird mit dem Done-Bit 
logisch ODER verknüpft und dann im Statuswort des Ori- 
ginal Request-Headers an der Stelle RH+3 gespeichert. 
Eventuell für diese Operation benötigte Zeichenzähler wer- 
den in der jeweiligen Routine aktualisiert. Wird eine Rou- 
tine von diesem Treiber nicht durchgeführt, gibt sie einen 
Status zurück, der angibt, daß sie beendet wurde. 


Die Initialisierungsroutine des Treibers 


Die Initialisierungsroutine (Kommando 00) wird nur ein 
einziges Mal bei der Installation aufgerufen. Sie sollte das 
Gerät für die folgenden Operationen vorbereiten und kann 
eine Nachricht auf dem Bildschirm ausgeben. Zu Test- 
zwecken in der Entwicklungsphase können Sie auch das 
Codesegment des Treibers ausgeben. 

Sie können nur MS-DOS-Funktionsaufrufe mit Funk- 
tionscodes (im Register AH) kleiner oder gleich OCH und 
die Funktion 30H zum Ermitteln der Versionsnummer 
durchführen. Da einige der Funktionen versionsspezifisch 
sind, werden Sie möglicherweise die Version ermitteln, ein 
Flag setzen, oder entsprechende Aktionen durchführen, 
wenn die falsche Betriebssystem-Version läuft. 


Tu _\ 








com port dv KRUSE der seriellen En 
stelle. OOMI = 8, COM2 = 
init_data db naamanıb + ; Initialisterungsöyte 
; Details entnehmen Sie dem BIOS 
'enzhandbuch 


3 { Techni: Referı 


‚block_num dvB ; Aktuelle Blocknumser der 

; Übertragung 
abort_xfer dv 8 ; momentanen Transfer abbrechen 

; (True = Ja) 
nak_ent dB ; Anzahl erhaltener/gesendeter NAKs 
BL flag dv ß ; Flag für CTRL-C 
he dB ; Anzahl nicht bearbeiteter Bytes 
in_block dv 8 ee ae 
vas_dialed de 8 ; Modem wurde angerufen 








Listing 2: Die IOCTL-Struktur für MDM_DRV. 


Es gibt spezielle Operationen für Block-Gerätetreiber, die 
hier aber nicht behandelt werden, die statische Tabellen 
verwenden, so daß MS-DOS später die Attribute des Block- 
geräts, die mit dem Treiber verknüpft ist, kennt. 

Beim Aufruf der Initialisierungsroutine des Treibers 
zeigt der Doppelwort-Zeiger an der Stelle RH+18 auf die 
Stelle hinter dem Gleichheitszeichen in der Befehlszeile aus 
der Datei CONFIG.SYS. So können Sie auch Aktionen ent- 
sprechend von Angaben in der Kommandozeile ausführen. 
MDM_DRYV zeigt diesen String am Bildschirm an. 

Die oberste Speicheradresse, die vom Treiber belegt 
wird, wird im Doppelwort an der Stelle RH+14 zurückge- 
geben. Diese Information teilt MS-DOS mit, wo es den 
nächsten Gerätetreiber laden kann. Da die Initialisierung 
nur einmal aufgerufen wird, kann zur optimalen Speicher- 
ausnutzung die Adresse dieser Routine selbst zurückgege- 
ben werden. Bedenken Sie, daß alles im Speicher hinter 
dieser Adresse überschrieben wird. 

MDM_DRV benutzt zwei Funktionen, die nur im MS- 
DOS der Version 3.x und höher verfügbar sind, die Routi- 
nen Device Open und Device Close. Frühere Versionen von 
MS-DOS wußten nichts von der Existenz dieser Routinen. 
Da diese benötigt werden, veranlaßt eine falsche Betriebs- 
system-Version die Beendigung des Treibers. 

MDM_DRV benutzt die Initialisierungsroutine, um sich 
zu vergewissern, daß es auf einem MS-DOS-System der 
Version 3.x läuft. Ist dies nicht der Fall, erfolgt die Ausgabe 
einer Fehlermeldung und der Abbruch. Sonst erfolgt die 
Initialisierung des Modem-Ports auf 1200 Baud, 8 Daten- 
bits, keine Parität und ein Stopp-Bit. 

Es gibt Alternativen zum Abbruch bei der falschen Ver- 
sion von MS-DOS. Mit etwas mehr Aufwand wäre es mög- 
lich, die Open-Funktion den ersten Lese- oder Schreibzu- 
griff ausführen zu lassen. Der letzte Aufruf oder eine ent- 
sprechende Pause nach einer Rückkehr von einem Lese- 
‚oder Schreibaufruf, könnte die Funktion Device Close auf- 
rufen. Ich beschloß, den Treiber nicht für die Version 2.x zu 
programmieren, schließlich ist es langsam Zeit, auf eine 
neuere Version umzustellen. Zuletzt wird eine Nachricht 
ausgegeben, und die Initialisierung ist abgeschlossen. 


Gerät öffnen 


Die Funktion Device Open (Kommandocode 0DH) hat 
keine definierte Funktion unter MS-DOS, aber Sie können 
sicher sein, daß MS-DOS Version 3.x diese vor jeder ande- 
ren Funktion aufruft, allerdings unter der Voraussetzung, 
daß das entsprechende Bit (Bit 11) im Header des Attribut- 
Blocks gesetzt ist. Der Treiber MDM_DRV benutzt dieses 
Bit für verschiedene Aufgaben. 

Beim ersten Aufruf erfolgt die Initialisierung des Kom- 
munikationsports mit den voreingestellten Werten. Diese 
Einstellung kann später mit dem Aufruf IOCTL geändert 
werden. Der Data Carrier Status wird überprüft, um zu er- 
kennen, ob der Port aktiv und mit einem anderen Computer 
verbunden ist. Wenn eine Verbindung besteht, wird die fol- 
gende Ruf- und/oder Antwortaktion übergangen. Ist der 
Computer nicht Online, wird eine Telefonnummer oder ein 
eturn) vom Benutzer erwartet. Wurde eine Nummer ein- 
gegeben, so wählt das Modem, ansonsten erwidert es den 
Anruf und wartet auf den Trägerton. (Ctrl)(c) führt zum 
sofortigen Abbruch. 

Nach Entdecken des Trägers wird eine sehr einfache 
Terminal-Kommunikationsroutine aufgerufen. Diese gibt 
an der Tastatur eingegebene Zeichen sowohl auf dem Bild- 
schirm, als auch am Kommunikationsport aus. Zeichen vom 
Kommunikationsport werden auf dem Bildschirm ausge- 
geben. Nach der Eingabe des Zeichens Escape auf einer der 
beiden Seiten verlassen beide Seiten die Routine und fahren 
fort. Nach der Eingabe von Escape wird der Timer in 
Beschlag genommen, da das Zeitverhalten ein kritischer 
Punkt des Xmodem-Protokolls ist. Am Schluß wird die 
Kontrolle dem ursprünglichen Anrufer übergeben. 




















Lesen 


Das Kommando READ (Kommandocode 04H) ist bei 
weitem die schwierigste Routine in MDM_DRV. 

Die aufrufende Routine (in den meisten Fällen MS- 
DOS) ruft die Funktion mit einer beliebigen Anzahl zu 
lesender Zeichen auf. Der Zeichenzähler ist im Request- 
Header an der Stelle RH+18. Die Zeichen werden an das 
aufrufende Programm zurückgegeben, indem sie sequentiell 
ab der Adresse, die an der Stelle RH+14 steht, gespeichert 
werden. 

Xmodem überträgt aber die Daten in festen, 128 Byte 
großen Blöcken mit einigen zusätzlichen Protokoll-Infor- 
mationen (schen Sie auch den gesonderten Teil über 
Xmodem). Es erwartet entweder das Zeichen ACK 
(Acknowledge) oder NAK (negatives Acknowledge) inner- 
halb einer bestimmten Zeit von der empfangenden Stelle. 
Hiervon kann abgeleitet werden, ob der Block richtig emp- 
fangen wurde. Stellen Sie sich vor, eine zeichenweise Über- 
tragung findet statt. Für den ersten Aufruf steht noch kein 
Zeichen bereit, so muß er auf die Übertragung eines Blocks 
warten. Wurde dieser Block nicht richtig übertragen, wenn 
also die Blocknummer, deren Komplement oder das Prüf- 
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summenbyte nicht so sind wie erwartet, oder wenn ein 
Timeout auftritt, dann wird ein NAK zurückgegeben und 
die Übertragungsschleife nochmal durchgeführt. Wurde der 
Block richtig übertragen, kann das ACK nicht gesendet 
werden, bis der Treiber bereit ist, einen neuen Block zu 
empfangen. Wenn das Programm TSRCOMM (auf Diskette) 
zur Verfügung steht, kann das ACK gesendet werden. 
(TSRCOMM erlaubt asynchrone Interrupts, wodurch ankom- 
mende Zeichen richtig empfangen werden.) Ist jedoch kein 
asynchroner Interrupt-Handler vorhanden, gehen Zeichen 
verloren, wenn das ACK unmittelbar gesendet wird. Es wird 
nicht gesendet, bevor die Zeichen im Block richtig verar- 
beitet und an der entsprechenden Stelle im Puffer des Auf- 
rufers gespeichert sind. Das bedeutet, daß die folgenden 
Aufrufe mit der Kenntnis, daß die Zeichen bereits im Puffer 
sind, durchgeführt werden müssen. 

Hierbei ergibt sich das Problem, daß es länger dauern 
kann, bis die 128 Zeichen durch die Treiberaufrufe bear- 
beitet sind, als zwischen dem Erhalten des letzten Zeichens 
und der Ausgabe von ACK oder NAK erlaubt ist. 

Wie sieht es in dem Fall aus, wenn viele Zeichen 
angefordert werden? Die Leseroutine muß wieder auf die 
Ankunft eines Blocks warten und dann so viele Zeichen 
bearbeiten, wie im Zeichenzähler im Request Header ange- 
geben sind, bevor sie zum aufrufenden Programm zurück- 
kehrt. Verlangt der Leseaufruf mehr Zeichen als im Puffer 
sind, so läuft die Routine in der Schleife »Block lesen/ 
Zeichen verarbeiten«, bis alle Zeichen übertragen sind. Die 
Routine aktualisiert auch den Zeichenzähler. 

Nach Beendigung der Leseanforderung wird die Kon- 
trolle wieder an den Aufrufer übergeben. Gab es zu viele 
NAKs, und der Transfer wurde abgebrochen, wird die 
Kontrolle mit gesetztem Fehlerstatusbit abgegeben. Die 
Kontrolle wird mit einem Fehlercode zurückgegeben, wenn 
ein EOT (Ende der Übertragung) empfangen wurde oder 
wenn Leseanforderungen nach einem EOT erfolgen. 


Eingangsstatus 


Das Kommando INPUT STATUS (Kommandocode 06H) 
ist für diesen Treiber nicht besonders nützlich, aber den- 
noch implementiert. Wenn ein Zeichen verfügbar ist (ein 
Block wurde empfangen, aber nicht vollständig bearbeitet), 
wird ein Status von 0 im Statusbit des Statusworts an der 
Stelle RH+3 zurückgegeben. Außer bei Leseanforderungen 
in Schritten von 128 Byte gibt diese Routine normalerweise 
nach dem ersten Lesen den Status »Zeichen bereit« zurück. 


Lesen ohne Entfernen 


Das Kommando NON DESTRUCTIVE READ (Komman- 
docode 05H) übergibt nur das Zeichen, das beim nächsten 
Lesen zurückgegeben wird. Es wird an der Stelle RH+13 
zurückgegeben, aber nicht aus dem Eingabepuffer entfernt. 
Was erfolgen soll, wenn der Eingabepuffer bei diesem 
Funktionsaufruf leer ist, ist nicht definiert. Daher wird ein 
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Fehlercode von OBH (Lesefehler) im Statuswort an der 
Stelle RH+3, und ein Zähler von 1 an der Stelle RH+18 
zurückgegeben. Als Zeichen wird das Fragezeichen zurück- 
gegeben. 


Eingabepuffer leeren 


Das Kommando FLUSH INPUT BUFFER (Kommando- 
code 07H) leert beim Aufruf den Eingabepuffer. Wird 
darauffolgend ein Leseaufruf durchgeführt, kann unter 
Umständen ein Timeout erfolgen, der veranlaßt, daß ein 
NAK gesendet wird. Das NAK veranlaßt, daß der letzte 
Block erneut gesendet wird, und somit ist alles in Ordnung. 


Schreiben 


Das Kommando WRITE (Kommandocode 08H) ist schr 
einfach, verglichen mit dem Lesen. Beim Schreibaufruf 
steht die Anzahl Byte im Request Header an der Stelle 
RH+18. Die Transferadresse ist im Doppelwort an der 
Stelle RH +14 enthalten. Die Zeichen werden sequentiell in 
den Ausgabepuffer übertragen. Enthält der Ausgabepuffer 
128 Zeichen, wird die Routine send_block aufgerufen. 
Der Block wird gesendet, bis er entweder erfolgreich über- 
tragen wurde oder genügend NAKs oder Timeouts von der 
Gegenstelle empfangen wurden, und somit einen Übertra- 
gungsfehler ergeben. 


Lesen mit Überprüfung 


Das Kommando WRITE WITH VERIFY (Kommando- 
code 09H) macht für einen Zeichentreiber wenig Sinn und 
besonders wenig Sinn für einen Treiber, der das Xmodem- 
Protokoll verwendet. Normalerweise sollte die Schreib- 
routine aufgerufen werden, dann sollten die Daten zurück- 
gelesen und verglichen, sowie bei Nichtübereinstimmung 
ein Fehler gemeldet werden. Im Falle des MDM_DRV 
‚genügt ein einfacher Aufruf der WRITE-Routine. 


Ausgabestatus 


Das Kommando OUTPUT STATUS (Kommandocode 
0AH) soll das Busy-Bit setzen, wenn das Ausgabegerät 
beschäftigt ist. Da MDM_DRV weder gepuffert noch inter- 
ruptgesteuert ist, ist dies möglich. Die Schreibroutine kehrt 
nie zurück, wenn nicht alle Aufgaben erledigt sind. Daher 
wird bei dem Rücksprung zum aufrufenden Programm das 
Busy-Bit nie gesetzt. 


Ausgabepuffer leeren 


Das Kommando FLUSH OUTPUT BUFFERS (Komman- 
docode 0BH) führt keine Aktionen in MDM_DRV aus, da 
das Leeren des aktuellen Ausgabepuffers schreckliche 
‚Auswirkungen auf die Transferroutine haben könnte. 


MS-DOS-(C 





Gerät schließen 


Das Kommando DEVICE CLOSE (Kommandocode 0EH) 
wird wie das Kommando DEVICE OPEN nur unter MS- 
DOS 3.x und bei gesetztem Bit im Attributwort des 
Headers aufgerufen. Dieses Kommando überprüft, ob noch 
ausstehende Zeichen zu senden sind und erledigt dies mit 
Hilfe der Routine send_block. Wahrscheinlich wird dies 
der Fall sein, da die Ausgaberoutine nur jeweils ganze 128 
Byte überträgt. Wird auf den abschließenden Block ein 
ACK empfangen, dann teilt die Routine der Gegenseite das 
Übertragungsende durch Senden von EOT mit. 

Diese Routine wird auch beim Übertragungsabbruch 
oder bei der Eingabe von [Ctri)(E) aufgerufen. Daher wird 
das Abort-Flag geprüft. Ist es gesetzt, wird das Zeichen 
CAN gesendet, welches der Gegenstelle signalisiert, daß der 
Transfer abgebrochen wurde. In diesem Fall wird der Rest- 
block nicht gesendet. War dies ein Anruf, wird der Hayes- 
kompatible Auflege-String gesendet. 

Schließlich wird am Modem-Port DTR zurückgesetzt, 
die verbogenen Interruptvektoren werden wieder auf die 
ursprünglichen Werte gesetzt, und die Kontrolle geht an das 
aufrufende Programm. 





Statusinformationen ans aufrufende Programm 


Das Kommando I/O CONTROL READ (Kommandocode 
03H) erlaubt zusammen mit dem Kommando 1/0 
CONTROL WRITE die Übergabe von Statusinformationen 
an das aufrufende Programm. Es ist nicht voll definiert und 
kann deshalb für alle möglichen Fälle verwendet werden. 

In MDM_DRV wird eine im Listing 2 dargestellte 
Struktur übergeben. Diese Information erlaubt es dem 
Anwendungsprogramm zum Beispiel, den Modemport zu 
definieren, den MDM_DRV benutzt. Das Anwendungspro- 
gramm kann auch erkennen, auf welche Werte diese Para- 
meter augenblicklich gesetzt sind. 

Bedenken Sie, daß die Zahl in RH + 18 angibt, wie viele 
Zeichen Sie auf diesen Aufruf zurückgeben dürfen. Da bei 
diesem Aufruf normalerweise ein Puffer mit begrenzter 
Länge verwendet wird, kann die Rückgabe von mehr Zei- 
chen an die Stelle in RH +14 das Schreiben in nicht korrekt 
allokierten Speicher bedeuten. In der Regel ist dies ein 
direktes Schreiben in einen Puffer des Anwendungspro- 
gramms, wobei ein Aufruf durchaus nur das erste Wort 
(Port der Kommunikation), anstatt der ganzen Struktur 
erhalten will. 


Informationen im Treiber setzen 


Das Kommando I/O CONTROL WRITE (Kommando- 
code OCH) erlaubt Ihnen auch Information an/vom 
Gerätetreiber zu übertragen. Dieses Kommando setzt 
Informationen innerhalb des Gerätetreibers. 

Die normale Benutzung ist ein Aufruf I/O CONTROL 
READ in einen lokalen Puffer, das Ändern der gewünsch- 


ten Daten und dann das Aktualisieren mit einem I1/O 
CONTROL WRITE Aufruf. 


Kommandos mit Dummyroutine 


Die Kommandos CHECK MEDIA (Kommandocode 01H), 
BUILD BIOS PARAMETER BLOCK (Kommandocode 
02H), REMOVABLE MEDIA (Kommandocode OFH) und 
OUTPUT UNTIL BUSY (Kommandocode 10H) werden 
vom Treiber MDM_DRV nicht verwendet, sind aber aus 
Gründen der Vollständigkeit im Treiber enthalten. In der 
Sprungverteilertabelle wird die gemeinsame Adresse einer 
Dummyroutine verwendet. 


Design-Überlegungen 


Es gibt Probleme bei der Gestaltung und dem Programmie- 
ren des Gerätetreibers, die anders geartet sind, als bei 
einem normalen Programm. In vielen Belangen sind der 
Entwurf und die Implementierung eines Gerätetreibers 
ähnlich einer Windows-Anwendung: Ihre Hauptroutinen 
werden von anderen Tasks aufgerufen, auch öfters; das 
System arbeitet nicht weiter, bis Sie die Kontrolle abgeben; 
die Schnittstelle ist starr definiert. 

Das erste Problem besteht darin: Es gibt keine Garantie, 
falls ein Device-Open-Aufruf durchgeführt wurde, daß auch 
ein Device-Close-Aufruf erfolgt. Um die Sache ein wenig 
verwirrender zu gestalten: Das einfache MS-DOS-Kom- 
mando COPY führt einige Device-Open- und Device- 
Close-Aufrufe aus, bevor es das Device für die Ein-/Aus- 
gabe öffnet. (Die wirkliche Sequenz kann Device Open, 
Device Close, Device Open, Lesen/Schreiben und Device 
Close sein.) 

Ein weiteres Problem des Gerätetreibers ist der Wie- 
derholungszähler. Irgendwo in den Tiefen von MS-DOS ist 
eine Zahl, die angibt, wie viele Wiederholungen Sie wün- 
schen, bevor der Gerätetreiber einen Fehler zurückgibt, und 
MS-DOS die Meldung »Abort, Retry, Ignore?« ausgibt. 
Dies wird vom Interrupt 24H, dem kritischen Interrupt- 
Handler erledigt. Es gibt keine dokumentierte Methode, 
nur einen Funktionsaufruf Device Open aufzurufen, und 
anschließend sofort den Interrupt 24H. Deshalb gibt es kei- 
nen sauberen Weg, wegen einer »toten Leitung« abzubre- 
chen. 

Da MS-DOS aus irgendeinem Grund außerhalb der 
Initialisierungsphase nicht vom Treiber aufgerufen werden 
darf, kann nur das BIOS für Zeichen-Ein-/Ausgabe aufge- 
rufen werden. Direktes Lesen von der Tastatur und direktes 
Schreiben in den Bildschirmspeicher funktionieren auch, 
erschweren aber die ganze Angelegenheit. Das bedeutet 
aber auch, daß ein Abbruch mit (Gtri)[C) nicht so funktio- 
niert wie Sie sich das wünschen, um vom Device Open Auf- 
ruf zum aufrufenden Programm bzw..MS-DOS zurückzu- 
kehren oder den kritischen Interrupt aufzurufen. 
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Dies ist ein weiteres schwieriges Problem, da MS-DOS- 
Gerätetreiber nicht beabsichtigen, ein interaktives Pro- 
gramm zu sein. Dies ist eine Herausforderung, die ich bis 
jetzt nicht richtig gelöst habe. Wenn Sie einmal den Treiber 
aufgerufen haben, gibt es keine Umkehr mehr. 

Das ist das kleinste Problem, wenn jemand mit MS- 
DOS Dinge unternimmt, für das es nicht gedacht ist. Dage- 
gen mußte ein Problem durch ein externes Programm 
gelöst werden: MS-DOS öffnet Zeichen-Gerätetreiber 
immer im Cooked-Modus. Wenn Sie eine Datei übertragen, 
und diese Datei ein CTRL-Z enthält, wird dieses als Datei- 
endezeichen verstanden, und die Datei wird sofort geschlos- 
sen. Deshalb muß der MDM_DRV im Raw-Modus arbei- 
ten. Wenn Sie es nicht selbst vorsehen, wird nicht garan- 
tiert, daß nach jedem Open-Aufruf auch ein IOCTL-Aufruf 
stattfindet, um den Treiber in den Raw-Modus zu schalten. 

Die Umstellung in den Raw-Modus hält nur für die 
Lebensdauer einer File Handle. Die weiteren Open-Aufrufe 
sind wieder im Cooked-Modus, bis Sie das kleine Hinter- 
grundprogramm SET_MDM laufen lassen. Dieses Pro- 
gramm fängt einfach den MS-DOS Interrupt 21H ab und 
prüft, ob ein Open mit File-Handle-Aufruf vorliegt. Ist dies 
der Fall, und die Adresse im Registerpaar DS:DX zeigt auf 
MDM (gefolgt von einer NULL), wird der Filemodus nach 
einem erfolgreichen Aufruf auf den Raw-Modus gesetzt. 
Dies ist für das aufrufende Programm transparent und 
erlaubt - wenn auch nicht besonders schön. 

Jeder Programmierer sollte ein vernünftiges Programm 
haben, mit dem er seine eigenen vergleichen kann. Ich 
schlage SET_MDM als neuen Standard vor. Aber wie 
immer, wenn Ihres funktioniert, ist dies in Ordnung. 


Verbesserungen 


Da MDM_DRV ein Beispiel für einen funktionierenden 
Gerätetreiber ist, ist der Code nicht ausgefeilt, und es gibt 
Möglichkeiten für die Verbesserung. 

Die Routine get_num prüft zum Beispiel nicht, ob das 
eingegebene Zeichen ein erlaubtes ASCII-Zeichen ist. Sie 
wartet nur auf ein Return oder bis zu 20 Zeichen. Eine gute 
Möglichkeit, diese Routine (oder jede andere im Treiber) 
abzubrechen, steht ganz oben auf meiner Liste für Verbes- 
serungen. Des weiteren erwartet der Treiber ein Hayes- 
kompatibles Modem an einem COM-Port. Diese Annahme 
ist fest in den Aufrufen dev_open und dev_close 
kodiert. Wird MDM_DRV für andere Modems oder mit 
anderen Geräten, die an die serielle Schnittstelle ange- 
schlossen sind, verwendet, so ist ein zusätzliches Programm 
notwendig - möglicherweise auch die Funktionen IOCTL. 

Das Protokoll ist einfach die Xmodem-Prüfsumme. Eine 
weitere Verbesserung wäre die Verwendung der verbesser- 
ten Xmodem-CRC-Berechnung. Die Implementierung der 
Verbesserungen erfordert keinen großen Aufwand. 

Ein Abbruch oder ein EOT wird nicht entsprechend der 
Spezifikation erledigt, da sofort abgebrochen wird. Die 
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Spezifikation verlangt, daß das erste CAN oder EOT mit 
einem NAK beantwortet wird, um sicherzustellen, daß es 
sich nicht um Leitungsrauschen handelte. 


Debuggen 


Die Entwicklung eines Programms erfordert Geduld und 
detektivisches Vorgehen, wenn ein Problem auftritt. Es ist 
aber schwierig, Gerätetreiber ohne entsprechende Hilfs- 
mittel zu testen. Es stehen aber keine geeigneten Hilfsmittel 
zur Verfügung, Sie müssen sich leider eigene schaffen. 

Das erste ist eine aktuelle Sicherungskopie Ihrer Platte 
und die Möglichkeit, das System ohne automatisches Laden 
des Gerätetreibers neu zu starten. Meine Methode ist eine 
Startdiskette mit CONFIG.SYS. Ich starte den Computer 
mit dieser Diskette, wenn ich den Treiber teste. Es folgen 
noch einige Vorschläge für das Erstellen von MDM_DRV: 


s Erstellen Sie den Gerätetreiber zuerst als normales 
COM-Programm. Schreiben Sie sich dann einen Simu- 
lator, der alle Funktionen aufruft und mit einem Debug- 
ger die Register sowie den Request-Header ansehen 
läßt. Das ist zwar nicht ganz ideal, da es Ihnen keinen 
Test unter den wirklichen Voraussetzungen erlaubt, es 
ist aber ein guter Start und erlaubt Ihnen den Übergang 
zur nächsten Methode. 

® Schaffen Sie ein Programmskelett, das noch keine Initia- 
lisierungsroutine beinhaltet. Die Interruptroutine sollte 
nur ein Registerpaar mit der Adresse des Request-Hea- 
ders laden, die Sie in der Strategy-Routine abgespeichert 
haben. Rufen Sie dann einen Interrupt auf, den Sie für 
sich reserviert haben. Sehen Sie hier ein Beispiel: 





interrupt proc far 
peh es 
bx 


mov es, cs:[old_segment] 
mov bx, es:lold-offset) 
int 6ßh 


pop bx 
es 


rei 
Anterrupt endp 





a Das setzt natürlich voraus, daß Sie eine Interruptroutine 
für diesen Interrupt installiert haben. Ich verwende 
Interrupt 60H, einen Interrupt für Anwender. Folgendes 
Programm können Sie vervollständigen: 





int6ß proc far 
call real_int_routine 
iret 

intsß endp 








Das erlaubt Ihnen, real_int_routine als eine Far- 
Routine mit einem FAR RET aufzurufen. Der Vorteil 
dieser Vorgehensweise ist, daß Sie ein einfaches TSR- 
Programm schreiben können, das den Interrupt über- 
nimmt und sich verhält, als wäre es ein Gerätetreiber. 





Wenn Sie es als TSR-Programm getestet haben, was mit 
Debuggern leicht möglich ist, können Sie den Code in 
den wirklichen Gerätetreiber ändern und sind bis auf die 
Initialisierung fertig. 

» Der hardwareunterstützte Debugger Periscope gestattet 
es, als public deklarierte Variablen irgendeinem 
Codesegment zuzuordnen. Wenn Ihre Initialisierungs- 
routine beim Starten das Codesegment anzeigt, können 
Sie auf einfache Weise ein Dummyprogramm erstellen, 
das mit der Symboltabelle geladen wird, die Scgmen- 
tadressen tauschen und den Treiber symbolisch debug- 
gen. Ab diesem Zeitpunkt debuggen Sie quasi ein nor- 
males Programm. 

s Beachten Sie, daß dem Gerätetreiber nur ein schr klei- 
ner Stackbereich zur Verfügung steht. Es gibt keine 
Möglichkeit festzustellen, wieviel Speicher dem Geräte- 
treiber wirklich zur Verfügung steht. Der beste Weg ist 
das Speichern des Original-Stacksegments und des 
Stackpointers, das Benutzen eines eigenen Stacks und 
das Wiederherstellen des Originalstacks am Routinen- 
ende. MDM_DRV macht dies in der Interruptroutine. 

# Programmieren Sie den Gerätetreiber, als wäre er eine 
Hardware-Interruptroutine. Alle Register (und die 
Flags) müssen erhalten bleiben. Kritische Teile des 
Treibers sollten mit gesperrten Interrupts arbeiten 
(CLI). 

# Vergewissern Sie sich, daß der Zeichenzähler die An- 
zahl der wirklich bearbeiteten Zeichen wiedergibt. 
Falsche Zählerangaben haben sonderbare Auswirkun- 
gen. 

® Stellen Sie sicher, daß der Gerätetreiber keinen Spei- 
cher oberhalb der Adresse anspricht, die Sie bei der 
Initialisierung zurückgegeben haben. 

Ross M. Greenberg 





#5 NDM_DRV.ASM 
RR VE 


3 Tele ie AR 1 


segsent public "CODE" 
Der Treiber ist eine große Prozedur, die "driver" 
‚genannt wird. 
driver proc 
assune ee Die ister 
; müssen auf das zeigen 
org 8 ; Treiber muß bei 8 beginnen 
;; Header Gerätetreiber 
header! dd -1 ; Muß -1 sein. Wird von DOS gesetzt. 
dv Besdöh ; Zeichengerät 
} Manbe bi 
; is 
; Open/Close/RM unter: 
dv strat ; Zeiger zur Strategy-Routine 
dw ints ; ‚ger zur Iı ine 
db 'NDM Sr des Treil 


{ Linksbündig und 8 Zeichen lang 




















der Daten im Header 
itennummer (unbenutzt) 





Es 
5 - Reserviert für DOS 
; 13 - Media Beschreiber (unbenutzt) 
; vH ref für E/A 
; 18 - uns! int Zeichen E/A 
; 28 - Startsektor (unbenutzt) 
i3 Die Verteiler-Tabelle 
dispatch: 
dw init ; ExßO - Treiber ge 
du media_chk ; Exd1 - Media Prüfung (unbenutzt) 
dw bild bpb ; &x82 - Erstellen des BPB (unbenutzt) 
dw rd_Toctı + &x85 - IOCTL lesen 
du ; ExB4 - Lesen von "Anzahl’ Zeichen 
nn En ee yes lesen 
dw Inp_flush 1887 - Eingabegutfer leeren 
dv ; Exß8 - Zeichen en 
dv write viy + Ex89 - Schreiben zit Verifizierung 
ER i BeüR - Ausgabestatus 
I Ex - Ausgebepuffer en 
du wrt_foctl 3 Bxdc - I ‚schreiben 
dw open + ExßD - Device öffnen (DOS 3.x) 
dv dev_close x BxBE - ee ee 
dv ren_nedia 5 Br - ee See 
; um ( 
du out_busy } Bx1E - Ausgabe bis bereit (DOS 3.x) 
;; Strategy Routine 
si proc 
mov word ptr cs:[rh_ptr], bx 
SRIBRA REP Ares 
ri 
strat endp 





dispatch[bx] 


call word 
Ba cs:[rh_ptr] 





; DONE-Bit setzen 
wow a trat. Aistatus), ax ; im Status der Struktur 
POPALL 


elt 


mov ss, cs:[old stack + 2] 
EN sp, cs:lold;: | 
s 


ret 
ints endp 








Juli/August 1988 Microsoft System Journal 83 








5: READ ROUTINE 


read near 
Do 1 IN? nsg_ read 
mov ax, es:[di.count] 
mov cs:[inrequest], ax 
xor ax, ax 
mov es:[di.count], ax 
lds bx, es:[di.adress] 


ead: 
cs:[in_block], TRUE 
Ana Ipit- 
jap read_loop 


mov cs:[_incnt], FALSE 
mov si, offset cs:[_soh] 
mov cs:[tiner], 
mov cs:[nak ent], FNSE 
cap cs:[block_nun], 


top.n 





Ip_t 





Speichern des Anforderungsaählers 
Request Header Count 7 

8 setzen 

ds:bx zeigt auf Daten 


sind vir innerhalb des Blocks? 
Ja 


Setzen des Tiners 
NAK-Zähler zurücksetzen 
B Mal? 


Jnz rd_bik jein 
call  send_nak Senden des ersten NAK 
PA N LEFT_BRACKET [ anzeigen 
z ie A BE Can ; TEpaoe che Zeichen? 
er ; 
= Sul mat]; FALSE ; Irstes Zeichen? 
mp al,"ScH B Bertes Zeichen SOH? 
je Ime eiee ; Be Een 5 
al, ; ra enden‘ 
ja zo it : “> Abbruch 
cap al, ; nd 
Js senık u ‘ Bean 
ca) send a: i 
STAT _RIGHT_BRACKET ; ] ausgeben 
sur x ; und Zeilenvorschub 
xor ax,ax 
ret 
nxt_char: 
mov cs:[si], al ; Zeichen speichern 
ine cs:[_{nent] ; Zähler 
a oe ; Zeiger erhöhen 
r B 
cap es:[ Inent], FULLBLKSIZE; ‚end Bytes 
a an 
cap es:[tiner], FALSE ; Tine out? 
nz rd_bIk ; nicht -> erneuter Versuch 
SER DB ; Punkt anzeigen 
IK 
EL QUESTION ; Fragezeichen ausgeben 
"call send_nak ; NAK senden 
cap word ptr cs:[abort], ME; Abbruch? 
‚jnz rd_b1k3 De Te alten sen 
; versuchen 
abort_it: 
call send abort ; Abbruchzeichen senden 
call send-abort ; nochnal 
STAT  EXCLAIM ; beenden 
ade) sBöch ; Fehlerrückgabe 
re 
rd_bIk3: 
mov cs:[timer], TEN SECONDS ; Timer zurücksetzen 
FL rd_blk ; und nochaals versuchen 
ehkbik: 
mov ax, cs:[block_num] 
Bann ax 
; temporär 
= ni; Ko) ; Geller Block 
ran } nein 
xor ax, ei Be 
mov cs: Li a ax 
Jap ack_Blk 











mov ds: [bx), al 
ine bx 
ine si 
inc word ptr es:[di.count] 
dec cs:[_incnt. 
nz stf_nxt_char 
inc cs: Du num] 
STAT STAR 
ack_blk: 
“call send 
mov cs: (in! Blockl, FALSE 


top_read 
st£ as ar 
"dec cs: = Tinremest] 


Jnz rd_loop 
xor ax,ax 


endp 
WRITE ROUTINE 
write proc 


MX 
DO_F PRINT write 
won as: .1aiFeount] 


xor dx, 
1ds bx, es:[di.adress] 
mov si, cs:[_outptr] 
wr_ip: 
mov al, ds:[bx] 
mov cs:[si], al 


inc bx 

ine cs:[_outent) 

Se {_outent], BLKSIZE 
cs: . 

Sea wo 


call send block 
cap cs:[abort_xfer], FALSE 





near 


I abort 
mov es: a. ‚count], FALSE 
4 ax, ERROR + WRITE | 
re 


bIk_ok: 


; den aktuellen Block sichern 
; Ist der Blockzähler ok? 
; nein 


Block Konplesent 
nein 





; Zeiger zurücksetzen 


Zeichen nehmen 
und abspeichern 
beide Zeiger erhöhen 


Zähler erhöhen 
Restliche Zeichen vermindern 
; Neitere Zeichen 


; Stern anzeigen 


ACK senden 


noch Zeichen? 


keine mehr angefordert, 
kein Fehler © 


Wie viele Zeichen? 
Zeichen Zähler löschen 





; ds:bx = Zeiger auf Daten 


Zeichen 

im Puffer speichern 
Zeiger erhöhen 
Gesantzeichen Zähler 
aktueller Zeichen Zähler 
Block senden? 











eine Zeichen gesendet, 
Schreibfehler markieren 





mov cs:[_outptr], offset _buf; oh zurücksetzen 


mov si, offset buf 
mov cs:[_outent], FALSE 


ee zurücksetzen 
i Zeichenzähler zurücksetzen 


» Zeichenzeiger erhöhen 


Anzahl ter Zeichen 
Zeiger Soelehern 
keine Fi 
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DEVICE OPEN ROUTINE 


= Pa 








vov cs Toutptr], affset cs:_buf 
mov cs:[-outent], F) 

Be 

call set tIner 

:Tcon_port) 

Linit_data] 


» OOM-Port initialisieren 





ds:[com port] 
Sr ; Status lesen 
ah, 1 + Daten bereit 
ja continue s nein 
mov ah, 
Ant 14h ; Zeichen überlesen und 
je, eat_loop ; wiederholen 
continue: 
test al, B8ßh ; DCD an? 
6 off 1 
on_Tine 
ort.Ym 


mov dx, nee es:offline ; Nachricht ausgeben 


mov 
int 21h 

mov si, ann: es:nunbuf 

mov cx, ; maximale Länge 


call 
=‘ cs: Bes BE ; Nur RETURN? 


mov 2 effset cs:avait 
mov ah, 9 

Int 21h 

mov si, offset cs:answerstring 
call out_strii 
7 es:[tiner], 
1altR offline_lp 





; Warten auf Trägersignal 
u dx, offset cs:dialing 
mov ah, 9 


ine 2ıh 
mov si, offset cs:dialstring 
call out striı 


aov si, offset esemabuf 
call "out string 
mov si, offset cs:return 


call " out strii 
mov cs:[timer), ONE. MINUTE 
mov cs:[vas_dialed], TRUE 


offline_] 
Nah, Be L Mr i Online? 
mov dx, cs:[com por‘ 
int 14h a 


test al, Bdh 
jnz made_con 
call eat_char 
cap cs: [tier], 8 ; Time-out? 
nz offline_lp 

abort_call: 
mov cs:[vas_dialed], FALSE 
mov dx, offset cs:no_con 


mov 
Ant 21h 
xor ax, ax 
mov es:[di.count], 
mov ax, ERROR + ÖPAILURE 
POPALL_AX 
ret 
aade_con: 
wov dx, offset cs:con 
mov ah, 9 





Zähler auf @ setzen 
Fehlerhaft narkieren 














int 21h 


Fi 
mov dx, ds:[com port] 
int 14h 

al, ESCHE 


Bov Sn, offset cs:xfer 
aov ah, 9 
int 21h 
on_line: 
xor ax, ax 
POPRLLAX 
ret 


dev_open endp 


is DEVICE CLOSE ROUTINE 
dev, Ba 
"DO_PR! 


cap = ER ee 
Jnz 
Ba 

mov dx, cs:[com port] 
mov 


ıt 


Fe 
3 


„ ABORT 
0.send 

:[_outent], FALSE 
send 


Fr 
39" 


Dr 


iz 
call ” send block 
Ef RICHT, 


SIA ’ 
STAT 


2] 


mov cs:[ ip), ah _buf; Zeiger zurücksetzen 


mov si, offset 

mov cs: outent], ‚use 

inc cs:[block_num] 
no_send: 


mov 31 ‚offset cs:hangup 


5 ESCAPE -> Ende 


; Irgendvelche Zeichen 


» nein 
; Ja -> Zeichen einlesen 


; Statusmeldung 





; Abbruch? 
; nein 
} ABORT senden 


; normales Ende 
DR übrige Zeichen 
Ir raten 





ister zurücksetzen 
Zeichenzähler zurücksetzen 
4 vorsichtshalber... 
a ns 1 Block gesendet? 


nein 
; EOT senden 








; var ein Anruf? 
s eine Sekunde Pause 


; für CTRL-C 
; Pause vorbei? 





; eine Sekunde Pause 
; für CIRL-G 

ı Pause vorbei? 

; aufhängen 
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call  out_string 


no_hang: 

"mov cs:[vas_dialed], FALSE 

mov cs:[cancel flag], FALSE 
call reset Einer 


ret 
dev_close endp 


Die folgenden Routinen stehen im kompletten Programm 
an dieser Stelle: 
NON-DESTRUCTIVE READ ROUTINE 


INPUT STATUS ROUTII 

FLUSH INPUT BUFFER ROUTINE 
OUTPUT STATUS ROUTINE 
FLUSH OUTPUT ROUTINE 
READ 1/0 CONTROL ROUTINE 
WRITE 1/0 CONTROL ROUTINE 
'SEND_BLOCK ROUTINE 


INITIALIZE DRIVER ROUTINE 
ES 
Do_PRINT  msg_init 
mov ah, 
int 21h 
cap ah, 3 
Jge okay_dos 
mov dx, Offset cs:urong dos ; 
mov ah, 9 
int 2ih 
endiess_ loop: 
eli 
Jap endless_loop 3 nicht besonders schön 
okay“ dos: 
Bov dx, offset cs:greetings ; Nachricht ausgeben 
mov ah, 
int 21h 
push ds 
mov ds, es:[di.count + 2] 


mov si, es:[di.count] 
call" output_chars 


op ds 
> dx, offset cs:end_greetings ; Nachricht ausgeben 





; DOS Version bestinsen 
sion 3.x? 


icht ausgeben 





; it der Zeile der 
5 16.5YS Zeile 
: Offset 


mov ah, 9 
int 21h 
mov word ptr es:[di.address], offset init 
mov vord ptr es:[di.address + 2], cs 
xor ax, ax 
init endp 
wrong_dos db 22 Der Treiber mup unter DOS 3.8" 
db * oder höher laufen’, 
db CR, LF, "System ee s 
greetings db CR, LF, LF, 'MDM_DRV ist installiert...",CR,LF 
en db 'CONFIG.SYS Zeile ist : $' 
en 
te, @R, LF, LF, LF, 's" 
output_chars proc near 
output_loop: 
mov dl, ds:[si] ; Zeichen holen 
cap dl, LF ; Ende? 
Jnz outit } nein 
ret 
outit: 
mov ah, 2 ; Zeichen ausgeben 
int 21h 
Ka Altput : 
jap output_loop 
a endp 
driver en 
code ends 
end 














Listing 3: Beispielteile aus dem Gerätetreiber MDM_DRV. 
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Das Xmodem-Protokoll: 
Die fehlerfreie Übertragung eines Datenblocks 


Xmodem überträgt Daten in 128 Byte großen Blöcken, und zwar jeweils 
einen. Zusätzlich enthält jeder Block Inform: en, um sicherzustellen, 
daß die Übertragung fehlerfrei ist. Die zusätzliche Information, Prüf- 
summe genannt, ist eine Berechnung der Daten des Blocks. Die Kalkula- 
tion wird bei der Übertragung durchgeführt und das Ergebnis mit dem 
Block übertragen. Die empfangende Stelle führt dies ebenso durch und 
vergleicht das Resultat mit dem der sendenden Stelle. Weichen die beiden 
Ergebnisse voneinander ab, weist der Empfänger den erhaltenen Block 
ab, da er weiß, daß er falsche Daten empfangen hat. Die Zurückweisung 
erfolgt durch die Mitteilung, daß der Block falsch empfangen wurde. Der 
Sender sendet daraufhin den Block nochmals. Treten zu viele Fehler auf, 
kann eine Seite der anderen mitteilen, daß der Transfer abgebrochen 
wird. 

Das Xmodem-Protokoll ist ein vom Empfänger gesteuertes Protokoll. 
Der Sender wartet, bis der Empfänger einen Block anfordert. Die Anfor- 
derung gilt entweder dem nächsten oder dem letzten Block. 

Am Blockbeginn steht SOH (ASCII 01H), gefolgt von einem Byte, 
das die Blocknummer angibt. Darauf folgt das Einerkomplement (logisch 
NOT) der Blocknummer und anschließend die 128 Datenbyte. Das ab- 
schließende Byte enthält die Prüfsumme der 128 Byte. Andere Implemen- 
tierungen des Xmodem-Protokolls verwenden eine kompliziertere 2-Byte- 
Prüfsumme, die ein CRC-Check der 128 Byte darstellt. 

Wird der Empfänger zuerst angestoßen, sendet er ein NAK (ASCII 
15H), welches der Sender zur Synchronisierung der Xmodem-Prüfsumme 
verwendet. Wird das Zeichen »C« statt des NAK gesendet, dann wird die 
Xmodem-CRC-Prüfsummenberechnung verwendet. In jedem Falle sendet 
der Sender den ersten Block der Datei, den Block Nummer 1, wenn er das 
NAK oder das »C« erhält. 

Nach dem Senden jedes Blocks führt der Empfänger die gleiche 
Kalkulation durch und vergleicht sein Ergebnis mit dem des Blocks. Bei 
einer Abweichung liegt ein Übermittlungsfehler vor. 

Die meisten Empfänger ignorieren alle ankommenden Zeichen bis 
ein SOH empfangen wird, so daß der SOH-Teil die Prüfung ist, wodurch 
das Leitungsrauschen ignoriert wird. Die Blocknummer wird mit deren 
Komplement verglichen, um sicherzugehen, daß der Block in Ordnung ist. 
Ist es der erwartete Block, wird das ACK gesendet (ASCII 06H), und die 
Daten werden bearbeitet, indem sie normalerweise in einem Puffer abge- 
legt werden, der dann auf die Diskette geschrieben wird. Da viele Disket- 
tenkontroller den Interrupt sperren, wird die Schreiboperation oft vor 
‚dem Senden des ACK durchgeführt, damit keine Zeichen verlorengehen. 

Wenn die Blocknummer angibt, daß dies der letzte richtig erhaltene 
Block ist, so wird auch ein ACK gesendet, aber der Block nicht bearbeitet. 
Dies ereignet sich, wenn der Sender nie ein ACK für den angezeigten 
Block erhielt. 

Ein NAK wird gesendet, wenn kein ganzer Block innerhalb der Time- 
out-Periode empfangen wird, das nächste Zeichen nicht innerhalb einer 
kürzeren Timeout-Periode ankommt oder einer der oben angegeben Prü- 
fungen ergibt, daß ein Fehler vorliegt. 

Wenn der Sender ein NAK erhält, zählt er einen Zähler hoch, der 
beim Erhalt eines ACK zurückgesetzt wird. Erreicht der Zähler einen 
gewissen Wert, so schickt der Sender ein CAN-Zeichen (ASCII 18H) und 
bricht die Übertragung ab. In einem Protokoll, das nicht stabil ist, bricht 
der Empfänger unmittelbar ab und ignoriert alle erhaltenen Daten. In 
einem robusten Protokoll wird das CAN mit NAK beantwortet, der Sen- 
der schickt das CAN nochmals, und beide Seiten brechen den Transfer 
ab. Ist der NAK-Zähler noch nicht auf dem Höchststand, wird einfach der 
letzte Block nochmal gesendet. Wird weder ein NAK noch ein ACK erhal- 
ten, tritt möglicherweise ein Timeout ein, welcher wie ein NAK behandelt 
wird. “ 
Entweder wird die Übertragung abgebrochen, oder es wird ein Datei- 
endekennzeichen (EOF) gesendet. Wird das EOF erhalten, wird ein Ende 
der Übertragung (EOT, ASCII 04H) gesendet. Wird eine nicht robuste 
Version des Xmodem-Protokolls verwendet, wird sofort abgebrochen. In 
einer robusten Version wird NAK erwidert, das EOT nochmals gesendet 
und abgebrochen. 

Xmodem ist aus mehreren Gründen das beliebteste Protokoll in der 
Kommunikation und der Dateiübertragung im PC-Bereich: Es wurde früh 
entwickelt (am Ende der 70er Jahre). Es ist einfach zu implementieren, es 
ist effizient, und das wichtigste: es funktioniert. 
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